コンパイラの構築では、主な曖昧さの問題の1つは、dangling elseです。 Aho、Lam、Sethi、Ullmanの「コンパイラ:原則、テクニック、ツール」に記載されているように、dangling elseの文法はLL(1)パーサーでは使用できません。LL(1)他にぶら下がった文法
LL(1)には対応できないのは本当ですか?
コンパイラの構築では、主な曖昧さの問題の1つは、dangling elseです。 Aho、Lam、Sethi、Ullmanの「コンパイラ:原則、テクニック、ツール」に記載されているように、dangling elseの文法はLL(1)パーサーでは使用できません。LL(1)他にぶら下がった文法
LL(1)には対応できないのは本当ですか?
その真実は、純粋な形でLL(k)またはLALR(k)によって解析することはできません。問題は、ぶら下がったelseの解釈が2つあります。その曖昧さの問題(「else」は最も近い「if」に属しているか、または属していない)。
通常、硬化であり、2つの解釈のうちの1つ、例えば「elseが最も近いif」に限定されています。
多くのパーサージェネレーターは、これを「偶然によって」得ることができます。 LLを使った解法は最初の構文解析を受け入れ、最初に "else attached to closest"を試みることです。 LRを使用するソリューションは、アクションを「減らす」前に単に「シフト」アクションをチェックするだけで簡単に発生する「他のシフト」です。
これは、GLRなどのあいまいな解析を実際に拾うパーサーでのみ問題になります。ここでは、文法的なヒント、例えば「他のものにシフト」を提供することができる。