3

環境：

パーサーについて学んだとき、コード (C++ など) をコンパイルするプロセスは次のように説明されていました。

  1. コードをファイルに記述して保存します。
  2. ファイルをコンパイラに入れます。
  3. コンパイラは、まずコードを抽象構文ツリーに解析します。
  4. 次にマシンコードを生成します。
  5. コードを実行してテストします。
  6. 繰り返す。

Bret Victor は、入力時にコードを評価する一種のプログラミング環境を求めていました。( http://worrydream.com/#!/InventingOnPrinciple )

その概念を 2D ゲーム プログラミングを超えた汎用プログラミングに変換するには、いくつかの概念的な問題があるかもしれないということは、彼が初めてではなかったと思います。スモールトーク。

それは私が議論したいことではありません。

質問: (大雑把で申し訳ありません。主な質問は太字で示しています)

編集中にテキストを解析するにはどうすればよいでしょうか? エディターがテキストの一部が変更されたことを示すイベントを送信するたびに、AST の一部のみが再評価され、AST のこの部分の影響を受ける値も再評価されるという考えがありました。

私は、通常のように文法を使用するパーサー ジェネレーターを作成することを考えましたが、テキスト全体ではなく、テキストの増分変更を処理するパーサーを生成します。

1. これは合理的な概念ですか? （あいまいなプログラミング言語/環境の場合。おそらく「機能的リアクティブ」なもの。または単にhtml。）

(2.) まだ使用されているのでしょうか?

(3.) ファイル全体の解析は、複雑なアプローチを不要にするのに十分な速さですか?

(4.) Eclipse などの IDE の構文ハイライターまたはタイプチェッカーはこのように機能しますか? 代わりに、それらはどのように機能しますか? それらはコンパイラーパーサーほど強力ではなく、十分に高速に動作しないと思いますが、そうですか?

(5.) この Stackoverflow には、スタイル設定されたテキストのライブ プレビューがあります。キーストロークごとに質問全体を解析しますか? 「私の」コンセプトが解決するいくつかの制限はありますか?

4

3 に答える 3

4

タブ補完 (または「インテリセンス」) は、適切な補完/フォローが何であるかを把握するために、解析に非常に似たものを必要とします。おそらく、いくつかの IDE でそれを経験したことがあるでしょう。もしそうなら、あなたはその制限のいくつかにも気づいているでしょう.

SO のプレビュー機能のようなシステムは定期的に入力を解析しますが、すべてのキーストロークであるとは限りません。特にバッファーがいっぱいの場合、構文の強調表示が少し遅れることに気付くかもしれません。典型的な戦略は、解析中に入力が変更されなくなるまで繰り返し再解析し、次の変更を待つ単一のプロセスを持つことです。

vim や emacs などのテキスト エディターは、キーストロークごとに再解析しますが、(通常は) 行末でコンテキストをキャッシュすることによって最適化するため、再解析は数文字のみになります。(もちろん、完全な解析を行うわけではないので、さらに簡単です。)

インクリメンタル構文解析と抽象構文ツリーのインプレース編集に関する研究がいくつかありましたが、非常に扱いにくいものになっています。このスタイルに自然に役立つ構文解析戦略の 1 つに、「packrat 構文解析」があります (詳細な参考文献は、こちら から入手できます)。

C++ は正しく解析するのが難しいことで知られています。<実際、与えられたものがテンプレートブラケットなのか小なり記号なのかを判断するのは自明ではありません。一般に、すべてのヘッダー ファイルを読み取らずにこれを行うことはできません。場合によっては、テンプレートをインスタンス化しないと理解できません。これはインタラクティブに行うには多すぎる作業です。他の多くの言語は解析が容易であり、定期的に再解析するという単純なソリューションは、すべての実用的な目的に対して十分に高速です。

それがあなたの質問のほとんどに当てはまることを願っています。

于 2013-02-03T01:22:45.673 に答える
2

これは非常に興味深い質問です。GoWorks デモンストレーション IDE で説明されているものと多少似たパーサーを使用しています。これは、パーサーの動作を示すビデオです (5 分目から始まります)。

Tunnel Vision Labs の GoWorks IDE の紹介 (プレビュー リリース 7)

パーサーは毎回ファイル全体を解析するわけではありません。必要な解析情報は入力のサブセットからしか得られないからです。これ以上の解析には、次の主要な項目を含むいくつかの欠点があります。

  1. ファイルの不要な部分を解析し、それらの部分に構文エラーが含まれている場合 (ユーザーがアクティブに編集している場合によくあるケース)、パーサーはエラーから正確に回復できない場合があります。
  2. ユーザーには「スムーズ」に見えるほど高速であっても、必要以上に多くの情報を解析すると、移動中のユーザーのバッテリー寿命に大きな影響を与えます。

私の知る限り、私たちの最新の IDE は、複数の言語の一般的なアプローチとして、使用する特定のスタイルのパーサー (IDE で使用するために設計されたものの非常に具体的なサブセット) を積極的に使用している唯一のものです。

于 2013-02-03T04:28:14.663 に答える
1

ほとんどの場合、次の 2 つの方法のいずれかで行われます。

  • 色を付けるのに十分な情報だけを含む、はるかに単純な生のパーサーを使用します。シンプルなため十分に高速ですが、複雑な言語機能につまずく可能性があります。
  • 位置情報を AST に入れ、ツリーを修正するだけです。ある程度の履歴を残しておけば、現在の間違い以降のすべてを間違いとしてマークすることを避けることができます。

もちろん、Smalltalk は一度に 1 つのメソッドだけを解析します。これにより、ソリューションがより迅速かつ簡単になり、誤って解釈することが少なくなります。入力中の再解析を制限できます。識別子が認識されない限り、その後の部分を再解析してもあまり意味がありません。

ずっと前に、これが非常にうまく機能する mac (および ac 1) 用の think pascal コンパイラがありました。

于 2013-02-04T13:22:35.563 に答える