7

ペット プロジェクトとして LALR パーサー ジェネレーターを作成しています。

私はパープル ドラゴン ブックを使用して設計を支援しています。そこから収集したことは、パーサーには 4 つのエラー回復方法があるということです。

  • パニック モード: コンパイラ設計者によって事前に選択されたシンボルが見つかるまで、入力シンボルのダンプを開始します。
  • フレーズ レベルの復元: 入力文字列を、現在の生産量を減らすことができるものに変更します。
  • エラー生成: エラーを文法に組み込むことでエラーを予測する
  • グローバルな修正: フレーズ レベルの回復のより複雑なバージョン (私が理解しているように)

そのうちの 2 つは入力文字列を変更する必要があり (これは避けたい)、他の 2 つはコンパイラ設計者がエラーを予測し、言語の知識に基づいてエラー回復を設計する必要があります。しかし、パーサージェネレーターも言語に関する知識を持っているので、同期トークンを事前に選択したり、文法をエラー生成で埋めたりせずに、解析エラーから回復するより良い方法があるかどうかに興味があります.

同期トークンを選択する代わりに、パーサーは、現在のプロダクションが同期トークンとして削減できるすべての非終端記号の後に続くシンボルを扱うことはできませんか? 私はそれがどれほどうまく機能するかを実際には考えていません.パーサーが進行中のプロダクションのチェーンをたどっていると思いますが、もちろんそれはボトムアップパーサーの仕組みではありません. 実行可能な状態を見つけようとして、あまりにも多くの無関係なエラーが発生するでしょうか? 無効な状態でパーサーを再開しようとしますか? エラーが発生したときに実際の解析プログラムが次にどこに行くべきかについて推論する必要がないように、パーサーテーブルに有効なエラーアクションを事前に入力する良い方法はありますか?

4

1 に答える 1

5

利用可能なすべてのプロダクションを盲目的に追跡しようとすると、簡単に行き止まりに陥ってしまいます。パーサージェネレーターが把握するのが非常に難しい言語について知っていることがあります。(たとえば、次のステートメント区切り文字にスキップすると、解析が回復する可能性が非常に高くなります。)

自動化された手順が試されていないというわけではありません。これについては、構文解析理論(Sippu & Soisalon-Soininen)に長いセクションがあります。(残念ながら、この記事は有料ですが、ACM メンバーシップを持っているか、優れたライブラリにアクセスできる場合は、おそらく見つけることができます。)

全体として、yacc 戦略は「ひどいものではない」、さらには「十分に良い」ものであることが証明されています。それを改善するよく知られた方法が 1 つあります。それは、本当に悪い構文エラー メッセージ (またはエラー回復の失敗) を収集し、それらが発生したときにアクティブな状態まで追跡し (これは簡単に実行できます)、その正確な状態と先読みトークンへのエラー回復手順。たとえば、Russ Cox のアプローチを参照してください。

于 2014-02-16T05:12:45.053 に答える