パーサーコンビネーターを使用し始めたとき、私の最初の反応は、構文解析と字句解析の人為的な区別のように感じたものからの解放感でした。突然すべてが解析されただけです！
しかし、私は最近、codereview.stackexchangeでこの区別を回復する誰かを示すこの投稿に出会いました。最初はこれは非常にばかげていると思いましたが、Parsecにはこの動作をサポートする機能が存在するという事実に疑問を抱きます。
パーサーコンビネーターで既にレキシシングされたストリームを解析することの利点/欠点は何ですか？
回答:
解析では、ほとんどの場合、文脈自由言語の分析を理解します。コンテキストのない言語は通常の言語よりも強力であるため、パーサーは（ほとんどの場合）字句解析の仕事をすぐに行うことができます。
しかし、これはa）非常に不自然b）しばしば非効率的です。
a）について、たとえばif式がどのように見えるかを考えると、IF expr THEN expr ELSE exprではなく、「i」「f」ではなく、いくつかのスペース、式が始まることができる文字などが考えられます考え。
b）には、識別子、リテラル、あらゆる種類のブラケットなど、字句エンティティを認識する優れた仕事をする強力なツールがあります。それらは、ほとんど時間をかけずに作業を行い、素敵なインターフェイスを提供します：トークンのリスト。パーサーのスペースをスキップする心配はもうありません。パーサーが文字ではなくトークンを処理する場合、パーサーはより抽象的になります。
結局のところ、パーサーが低レベルのもので忙しいと思うなら、なぜ文字を処理するのですか？ビットレベルでも書くことができます！ご存知のように、ビットレベルで動作するこのようなパーサーはほとんど理解できません。文字とトークンについても同じです。
ちょうど2セントです。
if = string "if" >> expr >> string "then" >> expr >> string "else" >> expr。
字句解析と構文解析を分離することは「良い習慣」であると提案する皆-私は同意しなければならない-多くの場合、字句解析と構文解析を単一のパスで実行すると、より多くのパワーが得られ、パフォーマンスへの影響は、その他の回答（Packratを参照）。
このアプローチは、1つの入力ストリームにさまざまな言語を混在させる必要がある場合に役立ちます。これは、のような奇妙なメタプログラミング指向言語で必要とされるだけでなく、Katahdinと同様に HTMLにJavascriptを詰め、コメントでHTMLを使用して、文芸的プログラミング（と言う、ラテックスを混合して、C ++）のように、より多くの主流のアプリケーションのためだけでなく、しかし、およびなど。
字句解析器は通常の言語を認識し、パーサーは文脈自由言語を認識します。各通常言語もコンテキストに依存しないため（いわゆる右線形文法で定義できる）、パーサーは通常言語も認識でき、パーサーとレキシカルアナライザーの区別は不要な複雑さを追加するようです：単一のコンテキスト-free grammar（パーサー）は、パーサーと字句解析の仕事をすることができます。
一方、コンテキストフリー言語の一部の要素を通常の言語（したがって、字句解析器）を介してキャプチャすると便利な場合があります。
したがって、構文解析を字句解析から分離することには、より単純なコンテキストフリーの文法で作業し、字句アナライザーでいくつかの基本的な（多くの場合ルーチン）タスクをカプセル化できるという利点があります（divide et impera）。
編集
私はパーサーコンビネータに精通していないので、上記の考慮事項がそのコンテキストでどのように適用されるかわかりません。私の印象では、パーサーコンビネーターを使用した場合、文脈自由文法は1つしかなくても、2つのレベル（字句解析/構文解析）を区別することで、この文法をよりモジュール化できます。前述のように、下の字句解析レイヤーには、識別子、リテラルなどの基本的な再利用可能なパーサーを含めることができます。
\alpha'_1 (K_0, \vec{T})。識別子です。
簡単に言えば、字句解析と構文解析は複雑さが異なるため、分離する必要があります。LexingはDFA（決定論的有限オートマトン）であり、パーサーはPDA（プッシュダウンオートマトン）です。これは、構文解析は本質的に字句解析よりも多くのリソースを消費することを意味し、DFAのみが利用できる特定の最適化手法があります。また、有限状態マシンの記述はそれほど複雑ではなく、自動化が容易です。
lexに解析アルゴリズムを使用するのは無駄です。
個別の解析/ lexの主な利点の1つは、中間表現-トークンストリームです。これは、lex / parseの組み合わせでは不可能なさまざまな方法で処理できます。
そうは言っても、優れた 'ol再帰的まともな方法は、パーサージェネレーターを学習するよりも複雑でなく、操作しやすく、パーサージェネレーターのルール内でグラマーの弱点を表現する方法を理解する必要があることがわかりました。