K.Maebashi's BBS

たびたびお邪魔します。 3章途中まで読み進めたのですが、わからないところがあったので教えてください。 P.102のcrowbar.lのソースで、59行目で整数型「([1-9][0-9]*)|"0"」、65行目で実数型「0-9]+\.[0-9]+」、78行目で例外「.」のトークンを切り分けているように見えます。 入力が、「123.456」だった場合、なぜ実数型のトークンと判断されるのでしょうか？ 疑問に思ったのは「123.456」を「123」を整数型トークン、「.」を例外トークン、「456」の整数型トークンと判断する方法や、「1」,「2」「3」「.」「4」「5」「6」を全て例外トークンとして扱うこともできそうな気がするのですが、そうならない理由がわからないためです。 （済みません。書籍に記述があるのに私が読み飛ばしてしまっているだけかもしれません。） また、整数トークンと実数トークン、"if"トークンと[ \t]トークンの関係から推測すると、例えば"for while other if"みたいな命令語もトークンとして定義できそうですが、その場合に.lファイルでの定義行（ルール順番）によっては動きが変わるものなのでしょうか？ 整数型の場合「....|"0"」と0をダブルクォーテーションで括っていますが、電卓のケースでP.36では、「(....|0|([0-9]....)」と0をダブルクォーテーションで括っていません。この違いが上の判断条件に影響しているのでしょうか？

>疑問に思ったのは「123.456」を「123」を整数型トークン、「.」を例外トークン、 >「456」の整数型トークンと判断する方法や、「1」,「2」「3」「.」「4」「5」「6」を >全て例外トークンとして扱うこともできそうな気がするのですが、そうならない >理由がわからないためです。 これは、lexがなぜ「123.456」を実数トークンとして解釈するのかがわからない、 ということでしょうか? lexは、「最長一致」でトークンを切り出します。つまり「123」や「1」よりも 「123.456」のほうが長いので、「123.456」は実数トークンとして解釈されます。 それについては本の中ではp.39の一番下の段落で説明しています。 >また、整数トークンと実数トークン、"if"トークンと[ \t]トークンの関係から >推測すると、例えば"for while other if"みたいな命令語もトークンとして >定義できそうですが、その場合に.lファイルでの定義行（ルール順番）によっては >動きが変わるものなのでしょうか？ 同じところに書いてある通り、lexはまず「最長一致」でトークンを切り出そうとし、 長さが同じなら、より前の規則、つまり.lファイルでの定義行が上のほうである 規則を優先します。 >整数型の場合「....|"0"」と0をダブルクォーテーションで括っていますが、 >電卓のケースでP.36では、「(....|0|([0-9]....)」と0をダブルクォーテーションで >括っていません。この違いが上の判断条件に影響しているのでしょうか？ これはどちらでも同じですね。なぜ片方だけダブルクォートで囲んだのかは、 すみませんがさすがに思い出せません……

なるほど、わかりました。回答ありがとうございました。 P.39は、正規表現の話だけかと思って（読み返した時に何度も何度も）読み飛ばしていました。この箇所の記述にlexの動きについて書かれていたのですね。失礼しました。 私が誤解していたのは、最初に現れたトークン定義にマッチした場合に、以降のトークン定義を無視するんだろうなぁと思っていたことです。 なので、P.39に記述について+と++のトークンについては、lexの記述では当然に最初に++の定義があってその後に+の定義があるものと思い込んでいました。実際には+と++はマッチする長さが違うのだからlexの記述では、どちらを先に定義しても動きは変わらないのですね。