なぜ字句解析と構文解析を分離するのですか？

ステートマシンからの単一のパスを使用してドキュメントを解析することが可能です。2つのパスを持つことの利点は何ですか？テキストをトークンに変換するレクサーと、それらのトークンの生産ルールをテストするパーサーがありますか？生産ルールをテキストに直接適用する単一のパスを用意していないのはなぜですか？

compilers parsers

— ブレント
ソース

関連：Programmers.stackexchange.com/questions/128888/…-

— ユーザー

これはすでにCS、stackexchangeで議論されており、レクサー+パーサーの表現力への回答に多くの非常に技術的なコメントがあります。しかし、さらに答えを出す余地があるかもしれません。

— babou

パイプラインスタイルの並列処理（非常に不均衡なステージとはいえ）が副次的な利点になるのではないかと思います。命令キャッシュとデータキャッシュの両方の動作も興味深い場合があります。コンパイル時間をどれだけ短縮できるか（もしあれば）は、特定のハードウェアに依存します。

— ポールA.クレイトン

（少なくとも私には）明らかな理由の1つは、スキャナーツールを個別に使用できることです。実際には、入力をスキャンするためにflexを頻繁に使用しますが、yaccの全機能を必要とすることはめったにありません。

— -jamesqf

それらを分離する必要はありません。人々はそれらをスキャナーなしのパーサーに結合します。

スキャナーレスパーサーの主な欠点は、結果の文法がかなり複雑になることです。字句解析を行う正規表現とトークンストリームで構文解析を行うコンテキストフリー文法の対応する組み合わせよりも複雑です。特に、スキャナーレス解析の文法はあいまいになりがちです。トークンストリームで動作する文法のあいまいさを取り除くのは簡単です。

専用の事前レキシングフェーズを使用することの実用的な利点は、後続のパーサーをレキシカルな詳細と結合しないことです。これは、字句および構文の詳細が頻繁に変更される初期のプログラミング言語の開発中に役立ちます。

— マーティン・バーガー
ソース

T

$T$

P

$P$

P

$P$

P_{T}

$P_T$

@babouはい、そうです。LL（k）で構成されたregular-expressionの形式の正式な結果がLL（k）から外れる、または同様のことを知りません。さらに、字句解析は通常、通常の言語では行われませんが、より強力なもの、つまり最長一致およびキーワード優先の拡張された通常の言語で行われます。正確な言語クラスとそのクロージャープロパティが何であるかはわかりません。

— マーティンバーガー

先読みに識別子の読み取りが含まれる場合、識別子の長さに（原則的に）制限がないため、コンポジションには制限のない先読みが必要です。

— -babou

@babouよく分かりません。最長のキーワードの長さが17文字の場合、それより長い文字列は識別子であるか、字句的に無効である必要があります。

— マーティンバーガー

ただし、識別子、または場合によっては文字列、数値、またはその他のリテラルは、17を超える個別のシンボルのシーケンスであり、実際に必要なトークンの前に立つことがあります。それは大きな先読みであり、無限です。最終的には非決定的な言語になる可能性があります。

— babou