演算子の左関連付けを維持しながら、文法の左再帰を削除する

この演習に問題があります：

λ計算の次のあいまいな文法をGとします。

E → v | λv.E | EE | (E)

ここで、Eは単一の非終端記号、λv.EはEの変数vに関する抽象化を表し、EEはアプリケーションを表します。

1. L（G '）= L（G）となるようなLL（1）文法G'を定義し、次の通常の規則を課すことでGのあいまいさを解決します。
   1. 抽象化は正しい連想です。
   2. アプリケーションは関連付けられたままです。
   3. アプリケーションは、抽象化よりも優先されます。
2. G 'のLL（1）解析テーブルと、文字列の解析時に取得された解析ツリーを表示しますλv1. λv2. v1v2v1。

あいまいさの設定の優先順位と関連付けを排除し、次の文法を取得しました。

E -> EF | F
F -> λv.G | G
G -> (E) | v

これはLL（1）ではありません。これは、生成E -> EFが再帰的に行われるためです。しかし、私が得るその生産から左再帰を排除します：

E -> FE¹
E¹-> FE¹ | ɛ
F -> λv.G | G
G -> (E) | v

これは要件1.2に準拠していません。

私はインターネットで解決策を探しましたが、左再帰を維持しながら左結合性を維持することは不可能のようです。

ただし、この演習は数年前にコンパイラの試験に出たので、正解があるはずです。

ご協力ありがとうございました。

左結合性とLL（1）解析の互換性

コンテキストフリー（CF）構文の使用における主要な不整合の1つにぶつかっただけです。構文解析ツリーが文の意図された構造を、その意味論に近い形で反映するように、特にapplicationなどの非結合演算子の場合、文法を選択したいと考えています。これは、言語学におけるCF文法の本来の意図とほぼ同じでした。しかし同時に、一部のタイプの文法のみを許容する構文解析技術に制約されています。

実際、解析ツリーが演算子の左結合性を反映する場合、構文解析ツリーの最上位のアプリケーションノードは、非パテサイズの連続するアプリケーションの最も右の項を必ず追加するため、文法は必ず左再帰的です。したがって、LL解析は問題外です。あなたが正しいです。

これには2つの方法があります。1つは、後の処理段階（ここではラムダ式の削減など）で使用するための厳密な「解析木」をパーサーに依存させることではありません。これは、構文解析ツリーから構築できるが、構造が異なる抽象構文ツリー（AST）の概念につながります。

他の解決策は、CF文法を受け入れるより一般的な構文解析手法を使用し、それに従って構文解析することです。一般的なCFパーサーは十分に開発されたテクノロジーです（そして、なぜLLがそれほど人気なのか不思議に思っています）

これらの相反する要件に対する適切な答えと考えられるものが何なのか、私にはわかりません。

私がやろうとしていることは、それらが相反する要件であることを示すことです。連想性と優先度の制約を満たす最初の文法を指定し、次にその文法を解析のためにLL（1）文法に変換します。

ジャーナルや試験に何かが現れたという事実は、それが正しいことを完全に保証するものではありません。そして、私も間違っているかもしれません...しかし、問題についての私自身の知識に加えて、いくつかのチェックを行いました。

この具体例について

そうは言っても、あなたが提案している最初の文法はまったく正しくないようです。λu.λv.vを生成する方法はありません。

知っておくべき1つのトリックは、最低の優先順位（抽象化）を持つ演算子（ここでは抽象化またはアプリケーション）から始めることです。演算式も同様です。

私の試み：

E  -> A | λv.E
A  -> FA'
A' -> A | ɛ
F  -> (E) | v

この文法はLL（1）であり、必要なプロパティを尊重する必要があります。