レクサーがそのパーサーに返すトークンのデータ型は何ですか？

タイトルで述べたように、レクサーはどのデータ型をパーサーに返す/与える必要がありますか？ウィキペディアが持っている字句解析の記事を読んだとき、それは次のように述べました：

コンピュータサイエンスでは、字句解析とは、一連の文字（コンピュータプログラムやWebページなど）を一連のトークン（識別された「意味」を持つ文字列）に変換するプロセスです。

しかし、上記の声明と完全に矛盾して、別のサイトで質問した別の質問（好奇心があればコードレビュー）が回答されたとき、回答者は次のように述べました：

字句解析プログラムは通常、文字列を読み取り、これを語彙素のストリームに変換します。語彙素は数字のストリームである必要があります。

そして彼はこの視覚を与えました：

nl_output => 256
output    => 257
<string>  => 258

後の記事で彼はFlex、既存のレクサーについて言及し、それを使って「ルール」を書くほうが、レクサーを手で書くよりも簡単だと言った。彼は私にこの例を与え始めました：

Space              [ \r\n\t]
QuotedString       "[^"]*"
%%
nl_output          {return 256;}
output             {return 257;}
{QuotedString}     {return 258;}
{Space}            {/* Ignore */}
.                  {error("Unmatched character");}
%%

私の洞察を深め、より多くの情報を得るために、WikipediaのFlexに関する記事を読みました。Flexの記事では、トークンを使用して、次の方法で一連の構文規則を定義できることが示されました。

digit         [0-9]
letter        [a-zA-Z]

%%
"+"                  { return PLUS;       }
"-"                  { return MINUS;      }
"*"                  { return TIMES;      }
"/"                  { return SLASH;      }
"("                  { return LPAREN;     }
")"                  { return RPAREN;     }
";"                  { return SEMICOLON;  }
","                  { return COMMA;      }
"."                  { return PERIOD;     }
":="                 { return BECOMES;    }
"="                  { return EQL;        }
"<>"                 { return NEQ;        }
"<"                  { return LSS;        }
">"                  { return GTR;        }
"<="                 { return LEQ;        }
">="                 { return GEQ;        }
"begin"              { return BEGINSYM;   }
"call"               { return CALLSYM;    }
"const"              { return CONSTSYM;   }
"do"                 { return DOSYM;      }
"end"                { return ENDSYM;     }
"if"                 { return IFSYM;      }
"odd"                { return ODDSYM;     }
"procedure"          { return PROCSYM;    }
"then"               { return THENSYM;    }
"var"                { return VARSYM;     }
"while"              { return WHILESYM;   }

Flexレクサーはキーワードの文字列を返しているように思えます。ただし、特定の数値に等しい定数を返すこともできます。

レクサーが数値を返す場合、文字列リテラルはどのように読み取られますか？単一のキーワードでは数値を返すことは問題ありませんが、文字列をどのように処理しますか？字句解析プログラムは文字列を2進数に変換する必要はありません。その後、パーサーは数値を文字列に変換します。字句解析器が文字列を返し、パーサーに任意の数値文字列リテラルを実際の数値に変換させると、はるかに論理的（かつ簡単）に思えます。

または、レクサーは両方を返すことができますか？私はc ++で簡単な字句解析プログラムを作成しようとしました。これにより、関数の戻り値の型を1つだけにすることができます。したがって、私の質問をするように私を導く。

私の質問を段落に凝縮する：レキサーを書いて、それが1つのデータ型（文字列または数字）のみを返すことができると仮定すると、どちらがより論理的な選択でしょうか？

一般に、字句解析および構文解析を通じて言語を処理している場合、字句トークンの定義があります。例えば：

NUMBER ::= [0-9]+
ID     ::= [a-Z]+, except for keywords
IF     ::= 'if'
LPAREN ::= '('
RPAREN ::= ')'
COMMA  ::= ','
LBRACE ::= '{'
RBRACE ::= '}'
SEMICOLON ::= ';'
...

パーサーの文法があります：

STATEMENT ::= IF LPAREN EXPR RPAREN STATEMENT
            | LBRACE STATEMENT BRACE
            | EXPR SEMICOLON
EXPR      ::= ID
            | NUMBER
            | ID LPAREN EXPRS RPAREN
...

レクサーは入力ストリームを受け取り、トークンのストリームを生成します。トークンのストリームは、構文解析ツリーを生成するためにパーサーによって消費されます。場合によっては、トークンのタイプを知るだけで十分です（例：LPAREN、RBRACE、FOR）。しかし、場合によっては、トークンに関連付けられている実際の値が必要になります。たとえば、IDトークンに遭遇した場合、後で参照しようとしている識別子を特定するときに、IDを構成する実際の文字が必要になります。

したがって、通常、次のようなものが多少あります。

enum TokenType {
  NUMBER, ID, IF, LPAREN, RPAREN, ...;
}

class Token {
  TokenType type;
  String value;
}

そのため、レクサーがトークンを返すとき、そのタイプ（解析に必要）と、それが生成された文字のシーケンス（後で文字列と数値のリテラル、識別子、等。）。非常に単純な集約型を返すため、2つの値を返しているように感じるかもしれませんが、実際には両方の部分が必要です。結局のところ、次のプログラムを異なる方法で処理する必要があります。

if (2 > 0) {
  print("2 > 0");
}

if (0 > 2) {
  print("0 > 2");
}

これらは、トークンタイプの同じシーケンスを生成します：IF、LPAREN、NUMBER、GREATER_THAN、NUMBER、RPAREN、LBRACE、ID、LPAREN、STRING、RPAREN、SEMICOLON、RBRACE。つまり、それらも同じものを解析します。しかし、実際に解析ツリーで何かをしているときは、最初の数値の値が「2」（または「0」）であり、2番目の数値の値が「0」（または「2」 '）、および文字列の値が' 2> 0 '（または' 0> 2 '）であること。

タイトルで述べたように、レクサーはパーサーを返す/与えるデータ型はどれですか？

「トークン」、明らかに。レクサーはトークンのストリームを生成するため、トークンのストリームを返す必要があります。

彼は既存のレクサーであるFlexに言及し、それを使って「ルール」を書くほうが、レクサーを手で書くよりも簡単だと言いました。

機械生成のレクサーには、迅速に生成できるという利点があります。これは、字句文法が大きく変わると思われる場合に特に便利です。それらには、実装の選択に多くの柔軟性が得られないことが多いという欠点があります。

そうは言っても、誰がそれが「単純」であるかを気にしますか？通常、レクサーの作成は難しい部分ではありません！

字句解析プログラムを作成し、1つのデータ型（文字列または数値）のみを返すことができると仮定した場合、どちらがより論理的な選択でしょうか？

どちらでもない。字句解析器には通常、トークンを返す「次の」操作があるため、トークンを返す必要があります。トークンは文字列でも数字でもありません。それはトークンです。

私が書いた最後の字句解析器は「完全忠実」字句解析器でした。つまり、プログラム内のすべての空白とコメントの位置を追跡するトークンと、トークン内のコメントを返しました。私のレクサーでは、トークンは次のように定義されました：

• 主要なトリビアの配列
• トークンの種類
• 文字単位のトークン幅
• 末尾のトリビアの配列

トリビアは次のように定義されました：

• トリビアの種類-空白、改行、コメントなど
• 文字のトリビア幅

そのため、次のようなものがあった場合

    foo + /* comment */
/* another comment */ bar;

トークンの種類を持つ4つのトークンとしてlexのであろうとIdentifier、Plus、Identifier、Semicolon、および幅3、1、3、まず識別子トリビアからなる主要有するWhitespace4の幅とトリビア末尾Whitespace1の幅とPlus全く主要トリビアを持っていないのと1つの空白、コメント、および改行で構成される末尾のトリビア。最終的な識別子には、コメントとスペースなどの主要なトリビアがあります。

このスキームでは、ファイル内のすべての文字がレクサーの出力で考慮されます。これは、構文の色付けなどの便利なプロパティです。

もちろん、トリビアが必要ない場合は、種類と幅という2つのトークンを簡単に作成できます。

トークンとトリビアには幅だけが含まれており、ソースコード内の絶対位置は含まれていないことに気付くかもしれません。それは意図的です。このようなスキームには次の利点があります。

• メモリとワイヤ形式でコンパクトです
• 編集時の再字句化が可能です。これは、レクサーがIDE内で実行されている場合に役立ちます。つまり、トークンの編集を検出した場合、編集前にレクサーをいくつかのトークンにバックアップし、前のトークンストリームと同期するまでレキシングを再開します。文字を入力すると、その文字の後のすべてのトークンの位置が変更されますが、通常、1つまたは2つのトークンの幅が変更されるだけなので、その状態をすべて再利用できます。
• すべてのトークンの正確な文字オフセットは、トークンストリームを反復処理し、現在のオフセットを追跡することで簡単に導出できます。正確な文字オフセットを取得したら、必要なときにテキストを簡単に抽出できます。

これらのシナリオを気にしない場合、トークンは種類と幅ではなく、種類とオフセットとして表すことができます。

しかし、ここで重要なことは、プログラミングは有用な抽象化を行う技術です。トークンを操作しているので、トークンよりも便利な抽象化を行うと、その下に実装の詳細を選択することができます。

一般に、トークンを表す番号（または使いやすい列挙値）とオプションの値（文字列、またはジェネリック/テンプレート値）を持つ小さな構造体を返します。別のアプローチは、追加のデータを運ぶ必要がある要素の派生型を返すことです。どちらも軽度の嫌悪感はありますが、実用的な問題に対する十分な解決策です。