コンパイラの作成コンパイラ-使用方法と機能に関する洞察

これは、言語設計で使用される概念をフレームワークの形で抽象化することを目的とした抽象化プロジェクトへの姉妹プロジェクトに焦点を当てた一連の質問の一部です。姉妹プロジェクトはOILexerと呼ばれ、一致時にコードインジェクションを使用せずに、文法ファイルからパーサーを構築することを目的としています。

構造タイピングに関連するこれらの質問に関連する他のいくつかのページは、ここに表示され、使いやすさはここにあります。フレームワークに関する問い合わせに関連するメタトピックと投稿する適切な場所は、こちらにあります。

特定の文法から解析ツリーの抽出を開始するところまで来ています。その後、DFAを使用して順方向パスを識別する再帰的降下パーサーが続きます（ANTLR 4のLL（*）と同様）。私はそれを開いて洞察を得るだろうと考えました。

パーサーコンパイラでは、どのような機能が理想的ですか？

これまでのところ、実装されているものの簡単な概要です：

1. テンプレート
2. 特定の時点で何が有効であるかを把握しながら、予測を先読みします。
3. ルール内のリテラルを取得し、それらがどのトークンからのものであるかを解決するルール「非文字化」。
4. 非決定的オートマトン
5. 確定的オートマトン
6. トークン認識のためのシンプルな字句状態マシン
7. トークンの自動化方法：
   • スキャン-コメントに役立ちます：Comment：= "/ *" Scan（ "* /"）;
   • 減算-識別子に便利です：識別子：= Subtract（IdentifierBody、Keywords）;
     • 識別子がキーワードを受け入れないようにします。
   • エンコード-ベースN遷移のシリーズXカウントとしてオートメーションをエンコードします。
     • UnicodeEscape：= "\\ u" BaseEncode（IdentifierCharNoEscape、16、4）;
       • 16進数の4遷移を使用して、Unicodeを16進数でエスケープします。これとの違い：[0-9A-Fa-f] {4}は、Encodeを使用した結果の自動化で、許可される16進値のセットをIdentifierCharNoEscapeのスコープに制限します。したがって、\ u005cを指定すると、エンコードバージョンは値を受け入れません。このようなことには重大な注意事項があります。控えめに使用してください。結果として生じる自動化は非常に複雑になる可能性があります。

実装されていないのはCST生成です。これを機能させるには、適切なコンテキストを引き継ぐように決定論的自動化を調整する必要があります。

興味のある方のために、T *y♯プロジェクトの元のフォームをかなり印刷したものをアップロードしました。各ファイルは他のすべてのファイルにリンクする必要があります。それらに従うために個別のルールでリンクを開始しましたが、時間がかかりすぎました（自動化の方が簡単だったでしょう）。

さらにコンテキストが必要な場合は、それに応じて投稿してください。

編集5-14-2013：特定の言語でステートマシンのGraphVizグラフを作成するコードを書きました。 これがAssemblyPartのGraphVizダイグラフです。言語の説明でリンクされているメンバーは、そのルールのダイグラフを含む相対フォルダーにrulename.txtを持っている必要があります。例を投稿してから一部の言語の説明が変更されました。これは、文法に関することを簡略化するためです。これが興味深いgraphviz画像です。

これは素晴らしい質問です。

私は最近多くの解析に取り組んできました、そして私見の主な機能のいくつかは：

• プログラム的なAPI-理想的には、ライブラリをインポートするだけで、プログラミング言語内から使用できます。GUIまたはBNFのようなインターフェースも使用できますが、ツール、IDE、静的分析、テスト、言語抽象化機能、プログラマーの親しみやすさ、ドキュメントジェネレーター、ビルドプロセスを再利用できるため、プログラム的なインターフェースが重要です。加えて、小さなパーサーでインタラクティブに遊ぶことができるので、学習曲線が劇的に減少します。これらの理由により、「重要な機能」リストの一番上に配置されています。

• @guyshermanが述べたように、エラー報告。エラーが見つかったとき、エラーがどこにあり、それが起こったときに何が起こっていたかを知りたいのです。残念ながら、バックトラックが発生したときに適切なエラーを生成する方法を説明するための適切なリソースを見つけることができませんでした。（ただし、以下の@ Sk-logicのコメントに注意してください）。

• 部分的な結果。解析が失敗した場合、エラーの場所の前にあった入力の部分から何が正常に解析されたかを確認できるようにしたいと思います。

• 抽象化。十分な機能を組み込むことはできず、ユーザーは常にもっと多くの機能を必要とするので、考えられるすべての機能を事前に理解しようとすると失敗します。これはテンプレートとはどういう意味ですか？

• 私はあなたの＃2（先読み予測）に同意します。良いエラーレポートを生成するのに役立つと思います。それは他の何かに役立ちますか？

• 解析が発生したときに解析ツリーを構築するためのサポート。

  • 具体的な構文ツリー。ツリーの構造は文法に直接対応し、後のフェーズのエラー報告のためのレイアウト情報を含みます。この場合、クライアントは適切なツリー構造を取得するために何もする必要はありません。文法に直接依存する必要があります。
  • 抽象構文ツリー。この場合、ユーザーはすべての解析ツリーをいじることができます

• ある種のロギング。これについてはよくわかりません。（たとえば）トークンを使用してHTMLドキュメントを生成する場合に、パーサーが試行したルールのトレースを表示したり、空白やコメントなどのジャンクトークンを追跡したりできます。

• 文脈依存言語を処理する能力。これがどれほど重要かわからない-実際には、文脈自由文法を使用して言語のスーパーセットを解析し、その後の追加のパスで文脈依存制約をチェックする方がきれいに思えます。

• カスタムエラーメッセージ。特定の状況でエラーレポートを調整し、問題をより迅速に理解して修正できるようにします。

一方、現在の進捗状況については最新ではありませんが、エラー修正は特に重要だとは思いません。私が気付いた問題は、ツールが提供する可能性のある修正が1）非常に多いこと、2）実際に行われた間違いに対応していないため、あまり役に立たないことです。うまくいけば、この状況が改善するでしょう（またはおそらくすでに改善しているでしょう）。

言語設計の経験はありませんが、ゲームエンジン用のIDEを作成していたときに、一度パーサーを作成するのは初めてでした。

私の意見では、最終的なエンドユーザーにとって重要なのは、意味のあるエラーメッセージです。特に地球を壊滅させるポイントではないことは知っていますが、逆に言えば、これが重要な意味を持つことの1つは、誤検知を回避できる必要があるということです。誤検知はどこから発生しますか？それらは最初のエラーでパーサーが転倒し、完全に回復することはありません。C / C ++はこのことで悪名高くなっています（ただし、新しいコンパイラは少し賢いです）。

代わりに何が必要ですか？ある時点で何が有効/無効であるかを知るだけでなく、有効でないものを取り、それを有効にするための最小限の変更を行う方法を知っておく必要があると思います。これにより、関連する誤ったエラーを生成せずに解析を続行できます。混乱している再帰的な降下に。この情報を生成できるパーサーを構築できると、非常に堅牢なパーサーが得られるだけでなく、パーサーを使用するソフトウェアにいくつかの素晴らしい機能が提供されます。

これが事実である場合、私は本当に難しい、または愚かに明白な何かを申し訳ないかもしれないことに気づいています。これがあなたが探している種類のものではない場合、私は喜んで私の答えを削除します。

文法には、「再帰ルールを残してはいけない」などの制限があってはなりません。今日広く使われているツールがこれを持っていることはばかげている、そしてyaccが正しく行ってからほぼ50年後のLL文法を吸うことしか理解できない。

正しい再帰の例（yacc構文を使用）：

list: 
      elem                  { $$ = singleton($1); }
    | elem ',' list         { $$ = cons($1, $2);  }
    ;

左再帰の例（yacc synatxを使用）：

funapp:
    term                    { $$ = $1; }
    | funapp term           { $$ = application($1, $2); }
    ;

さて、これは他のものに「リファクタリング」される可能性がありますが、どちらの場合でも、特定の種類の再帰はこれを書くための「正しい」方法です。 。

すべてを「リファクタリング」して、ツールが1つに課す左/右の再帰的フォームになるように要求するのではなく、自然な書き方をサポートする高度なツールから期待できます。