問題タブ [recursive-descent]

次の単純な「電卓式」文法（BNF）は、予測LL（1）である簡単な再帰下降パーサーを使用して簡単に解析できます。

選択するルールを知るには、次のトークンを確認するだけで常に十分だからです。ただし、次のルールを追加するとします。

次のような変数を使用して、コマンドラインで電卓を操作するために：

<command>単純なLL（1）予測パーサーを使用してルールを解析できないというのは本当ですか？そのためのパーサーを作成しようとしましたが、今後さらにトークンを知る必要があるようです。バックトラッキングを使用するソリューションですか、それともLL（2）を実装して、常に2つのトークンを先読みすることができますか？

RDパーサジェネレータがこの問題を処理する方法（たとえば、ANTLR）？

手書きの再帰降下パーサー (必然的に LL(k)) は、生成された LALR パーサーとパフォーマンスの点でどのように比較されますか?

LALR パーサーは LL(k) よりもはるかに多くの文法を処理できることを知っています。ただし、パーサーを手動で作成することが私の意図であり、再帰降下が最も適切な選択のようです。他の種類のものを手で (合理的に読みやすく) 興味を持って書くことは可能ですか?

注意: 私はテールコール最適化 (F#) を備えた関数型言語を使用しているため、[適切に調整された] 再帰は他の言語ほど問題になりません。

文法が与えられたときの RDP の FIRST、FOLLOW、および PREDICT セットの定義の適切な説明を探しています。

Perl & Parse::RecDescent を使用して、ファイルからいくつかのデータを解析しようとしています。RecDescent はデータ ファイルを調べるのに何日もかかるため、perl スクリプトで完全なデータ ファイルをスローすることはできません。そこで、実行時間を短縮するために、巨大なデータファイルを RD サイズのチャンクに分割しました。

ただし、バランスの取れた括弧内のセクションを抽出する必要があり、現在のルーチンは堅牢ではありません (改行からの最後の閉じ括弧の位置に大きく依存します)。例：

さまざまな量の間隔とサブセクションを持つことができるcell ... {一致する終了まで、すべてを取得する必要があります。}

これを簡単に行うには、Linuxコマンドラインの何かが必要ですか? 何か案は？

編集: 入力ファイルは約 8M、文法 ~60 ルールです。

私は最近、パーサー（言語/文脈自由文法用）がどのように機能するかを自分自身に教えようとしていますが、1つを除いて、そのほとんどは理にかなっているようです。特にLL（k）文法に注目しています。このアルゴリズムでは、2つの主要なアルゴリズムがLLパーサー（スタック/解析テーブルを使用）と再帰下降パーサー（単に再帰を使用）のようです。

私が見る限り、再帰下降アルゴリズムはすべてのLL（k）文法で機能し、場合によってはそれ以上で機能しますが、LLパーサーはすべてのLL（k）文法で機能します。ただし、再帰下降パーサーは、LLパーサーよりも実装がはるかに簡単です（LLパーサーがLRパーサーよりも単純であるのと同じです）。

だから私の質問は、どちらかのアルゴリズムを使用するときに遭遇する可能性のある利点/問題は何ですか？同じ文法セットで機能し、実装が難しいのに、なぜ再帰下降よりもLLを選ぶのでしょうか。

私は手動で再帰降下パーサーを書きたいと思っており、それを構造化する方法、アルゴリズムなどに関する優れたリソースを探しています.

質問は非常に簡単です：PEGを使用してPHPを解析することは可能ですか？PHPを解析するためにPEGパーサジェネレータを使用したいと思います。ご教授ください。ありがとうございました！

次の CSS を jQuery に置き換える方法はありますか?

私は精神の使い方を理解しました。つまり、適度に複雑な文法を書きました。私は常にプログラムを成長させるアプローチを取ります-一度に1つのサブシステム。最高レベルで4つのタイプを持つ複雑なモデルのデータ構造を記述しました。

ルールアプローチから構成された文法を使用して、一度に1つのタイプのトップレベルタイプを解析したいと思います。つまり、1つのトップレベルグラマーで4つのグラマーを記述したいと思います。これが可能である場合（私は疑い始めています）、誰かがこれを行うプロジェクトへのスニペットまたは参照を投稿してください。

50以上の（もっと多くの可能性がある）ルール（適切なエラー処理のため）を備えた1つのトップレベルの文法は、面白そうに聞こえません（TMPコードは揮発性/コンパイルが遅く、役に立たないエラーメッセージを提供します）。

解析する必要のあるモデルのスキーマのセクションがあります。次のようになります。

プロパティは次のとおりです。

1. 要素は順序付けられていないように見える場合があります。
2. スキーマの一部であるすべての要素が表示される必要があり、他の要素は表示されない必要があります。
3. 要素の合成された属性はすべて構造体に入ります。
4. （オプション）スキーマは将来、タイプフィールド（つまり、タイプに基づいて異なるフィールド）に依存する可能性がありますが、現時点ではこれについては心配していません。