これらのツールは基本的に、文法を入力し、一連のトークンを構文ツリーなどのより有用なものに処理するコードを出力します。しかし、これらのツールを代わりにライブラリの形式で作成することはできますか? ソース コードを出力として生成する理由は何ですか? パフォーマンスの向上はありますか? エンドユーザーにとってより柔軟ですか? yacc と ANTLR の作成者にとって、より簡単に実装できますか?
質問があいまいすぎる場合は申し訳ありませんが、作成者が下した決定の背後にある歴史的な理由と、自動生成されたコードが今日の環境でどのような目的を持っているかについて知りたいだけです。
パーサー ジェネレーターが文法規則の相互作用を相互に処理し、その結果をコードにコンパイルすることによって、大きなパフォーマンス上の利点が得られます。
単純に文法を受け入れて構文解析を行うインタープリターを構築することができます。実際にはそれが比較的得意なパーサータイプ（Earley）があり、オフラインではなく実行時に文法の相互作用を計算し（Earleyパーサーはとにかくこれを行います）、解析アルゴリズムを実行できます。
しかし、10 倍から 100 倍のスローダウンという解析パフォーマンスのペナルティと、おそらく大きなストレージ需要を支払うことになります。
非常に小さな文法のみを使用して解析している場合、または非常に小さなドキュメントのみを解析している場合、これは問題にならない可能性があります。しかし、多くのパーサー ジェネレーターが適用する文法も最終的にはかなり大きくなり (人々は言語で言えることを追加したいと考え続けます)、かなり大きなドキュメントを処理することになることがよくあります。そのため、パフォーマンスが重要になり、ビオラ、人々はコード生成パーサー ジェネレーターを構築します。
ツールがあれば、単純なケースでも使いやすいことがよくあります。パーサー ジェネレーターができたので、それらを小さな文法や小さなドキュメントの解析に適用することもできます。
編集：補遺。歴史的な理由は、おそらくスペースと時間の需要によって引き起こされます。以前のシステムには多くのスペースがなく (1975 年には 32Kb)、実行速度も遅く (1 MIPS の同じ時間枠)、人々はすでに大きなソース ファイルを持っていました。パーサー ジェネレーターは、この一連の問題を解決する傾向にありました。解釈された文法は、耐えられないほど悪いパフォーマンスを持っていたでしょう.
Ira Baxterは、実行時に文法解析を処理しない一連の理由を示しました。
別の理由もあります。文法の各規則に関連付けられているのは、適切なアクションです。アクションは通常、別の言語 (C や C++ など) の一部です。実行時に解釈される文法のすべてのアクションは、プログラム内の適切なものにマップ可能でなければなりません。一般的に、それは負ける命題です。フラグメントは、スタックの一部 ( 、 など) を参照したり、$$アクション$1を呼び出したり (YYACCEPTなど）。このようなフラグメントで確実に使用できるようにランタイム システムを設計するのは困難です。ソース コードを作成し、それを DSO (動的共有オブジェクト) または DLL (動的リンク ライブラリ) にコンパイルしてロードすることに興味があるでしょう。これには、顧客のマシンにコンパイラが必要です。顧客は、意図的にコンパイラを使用しないように生産システムを設計している可能性があります。