次のreduce-reduceエラー（LALR解析）を解決できません。

Question

現在、Decaf（プログラミング言語）文法の一部を実装しています。ここでバイソンコードの関連するスニペットは次のとおりです。

type: 
    INT 
    | ID 
    | type LS RS 
    ; 

local_var_decl: 
    type ID SEMICOLON 
    ; 

name: 
    THIS 
    | ID 
    | name DOT ID 
    | name LS expression RS 
    ; 

それにもかかわらず、できるだけ早く私は名前生成規則に仕事を始めとして、私のパーサはを減らす、削減警告を与えます。それは（バイソンによって生成された） .OUTPUTファイル内に何ここ

は：私たちは、次の入力{ abc[1] = abc; }を与える場合

State 84 

    23 type: ID . 
    61 name: ID . 

    ID  reduce using rule 23 (type) 
    LS  reduce using rule 23 (type) 
    LS  [reduce using rule 61 (name)] 
    $default reduce using rule 61 (name) 

そう、それはそのsyntax error, unexpected NUMBER, expected RSを言います。 NUMBERはの式のルール（基本的にどのように解析する必要があるのですか）ですが、local_var_declルールで解析しようとします。

この問題を解決するにはどうすればよいと思いますか？ 2時間ぐらい過ごして、別のものを試しましたが、うまくいかなかった。

ありがとうございました！

PS。ここにはlinkが完全に.yソースコード

Answer 1

これは十分な情報がある前にパーサーが決定を下すことが多い一般的な問題の特定のインスタンスです。このような場合には、必要な情報が遠く離れていない場合もあります。可能であれば、先読みを増やすだけで十分です。 （残念ながら、パーサジェネレータはk > 1のLR（k）パーサを生成しますが、bisonも例外ではありません）。通常は、解析を行わずに続けることができます。 bison（ただしCモードのみ）の別の解決策は、%glr-parserを求めることです。これは、処理時間を追加することで削減を解決する必要がある場合にはさらに柔軟になります。この場合

、コンテキストは[（LS）続いIDで開始することができ、どちらもtype又はname、のいずれかを可能にします。 nameの場合は、[の後に数字を付ける必要があります。 typeの場合、[には]が続かなければなりません。したがって、IDの後に2番目のトークンが表示されたら、すぐに決定できます。

しかし、トークンは1つのみ表示されます（]）。文法は、あるケースではIDをnameに、それ以外の場合はtypeに減らさなければならないので、すぐに決定できると主張しています。ですから、バイソンは文法ファイルの最初のものがどれになるかを常に使って解決するreduce-reduceの衝突があります。

1つの解決策は、この選択を強制することではなく、制作物を複製することです。例：

type_other: 
    INT 
    | ID LS RS 
    | type_other LS RS 
    ; 
type: ID 
    | type_other 
    ; 

name_other: 
    THIS 
    | ID LS expression RS 
    | name_other DOT ID 
    | name_other LS expression RS 
    ; 
name: ID 
    | name_other 
    ;