決定的な答えを得るには、FunctionCall と (特に) Expression の定義を確認する必要がありますが、私の推測では、Expression は単一の Ref または Value のいずれかになります。この場合、代入の右側にある Ref/Value をそれ自体として直接解析するか、単純な式として解析するか (確かに) わからないと言っています。
驚くべきことは、 FunctionCall が同様のあいまいさを生成していないことです。これは、 Expression の定義が、少なくとも欠陥に近いという点でおそらく奇妙であることを示している傾向があります。
もし私がそうしていたら、Assignment の定義を次のように変更するでしょう:
%left '-' '+'
%left '*' '/'
%%
Assignment: Ref '=' Expression;
Expression: Value
| FunctionCall
| Ref
| Expression '+' Expression
| Expression '-' Expression
| Expression '/' Expression
| Expression '*' Expression
| '(' Expression ')'
;
もちろん、基本的な 4 つよりも多くの演算子をサポートしたい場合もありますが、それを推測するのは困難です。少なくとも合理的なアイデアを提供するのに十分な数を投入しようとしました。
いずれにせよ、この構造では、割り当ての右側が式でなければならないことに疑問の余地はありません。式には、リストした 3 つの基本的な項目を任意の算術演算子と組み合わせて含めることができるため、次のようになります。
x[i] = a[2] + 1 + f(3)
(漸進的に) なる必要があります:
Ref = Expression
Ref = Expression '+' Expression
Ref = Expression '+' Expression '+' Expression
Ref = Ref '+' Value '+' FunctionCall
ID '[' ID ']' '=' ID '[' Value ']' '+' Value '+' FunctionCall
(そして FunctionCall はおそらく次のようにさらに削減されます:ID '(' Value ')'
結論: 文法の少なくともこの部分は、本質的に S/R 競合の影響を受けません。トップレベルAssignment
から特定の割り当ての個々のトークンへの明確で明確なパスがあります。これは、すべての式の構文が同じであるため、ユーザーの混乱を軽減するのにも役立ちます。