プロダクションコンパイラはパーサジェネレータを使用しますか？

Question

「実際のコンパイラライター」はパーサージェネレータを使用するのではなく、手作りのパーサを使用すると聞いています。私はまた、パーサジェネレータが現実の言語のためにそれをカットしないと聞いてきました。おそらく、パーサジェネレータを使用して実装することが困難な特殊なケースが数多くあると思われます。私はこれについての私の疑問を持っている：

1. を理論的には、GLRパーサジェネレータは、ほとんどのプログラミング言語の設計を処理できる必要があります（++多分Cを除いて...）
2. は、私が使用して、少なくとも1つの製造言語を知っていますパーサージェネレータ：Ruby [1]。
3. 私は学校でコンパイラクラスを取ったとき、パーサジェネレータを使用しました。

私の質問：パーサージェネレーターを使用してプロダクションコンパイラーを書くのは妥当ですか、コンパイラーコミュニティによる設計上の決定が不適切であると考えられるパーサージェネレーターを使用していますか？何が価値があるために

[1] https://github.com/ruby/ruby/blob/trunk/parse.y

Answer 1

、GCCは、維持・拡張するために簡単だったので、手書きの再帰下降パーサに切り替え、その後、私は信じているパーサジェネレータ事前4.0を使用していました。

パーサージェネレータは「実際の」言語では「カット」しますが、文法を実行可能なものに変換する作業量は指数関数的に増加します。

編集：GCC文書にリンクし、変更理由と利点とコスト分析を比較して説明します。http://gcc.gnu.org/wiki/New_C_Parser。

Answer 2

時には両方の方法の組み合わせが使用されます。たとえば、パーサーでコードを生成し、後でそのコードで「手作業で」修正します。

他の方法として、スキャナ（レクサー）やパーサーツールでは、「セマンティックアクション」と呼ばれる文法規則に加えてカスタムコードを追加することができます。この例の良い例は、パーサーがジェネリック識別子とカスタムコードを検出し、特定の識別子をキーワードに変換することです。

EDIT： 私たちは多かれ少なかれ書き込みコンパイラた数年間、会社のために働いていた「セマンティックアクション」

Answer 3

を追加します。パフォーマンスにはあまり関心がありませんでした。作業/保守の量をわずかに減らすだけです。これを実現するために、生成されたパーサーと手書きのコードの組み合わせを使用しました。理想的なバランスはパーサジェネレータで簡単で反復的なパーツを自動化し、カスタム関数で難しい問題に取り組むことです。