問題タブ [shift-reduce-conflict]

バイナリの合計/積の解析は簡単ですが、解析する文法を定義するのに問題があります

なので

私の最初の（ナイーブな）試みは、61シフト/競合の削減を生み出しました。

私はJavaカップを使用しています（ただし、他のパーサージェネレーターのソリューションは簡単に変換できると思います）。

私はCUPを使用して、自分の論文に必要なパーサーを作成しています。文法にシフト/リデュースの競合があります。私はこの生産ルールを持っています：

そして私はこの警告を持っています：

今、私は実際にそれをシフトしたかったので、私はそれでかなり大丈夫です、しかし私の教授は私に対立を解決する方法を見つけるように言いました。わたしは目が見えない。私はいつもif/elseの競合について読んでいますが、私にはそうではないようです。手伝って頂けますか？

PS：IDENTIFIER、LPAREN "（"およびRPAREN "）"は端末ですが、parlistおよびcommandはそうではありません。

私はSableCCと文法定義を初めて経験しました。私は次の文法（その一部）を持っています：

次のエラーがあります。

私はすべての選択肢にl_parとr_parを追加することでそれらを解決しました。ちなみに、読みやすさを向上させるはずですが、エレガントな方法でそれを行う方法はありますか？

ありがとう。

型名が大文字で始まり、変数名が小文字で始まる、私が設計した言語用のパーサーを構築しています。これにより、レクサーは違いを認識し、異なるトークンを提供できます。また、文字列 'this' はレクサー (OOP 言語) によって認識され、別のトークンとして渡されます。最後に、データ メンバーは「this」オブジェクトでのみアクセスできるため、次のように文法を作成しました。

Expression の最初の規則により、ユーザーは「this」を値として渡すことができます (たとえば、メソッドからそれを返すか、メソッド呼び出しに渡します)。2 つ目は、「this」のデータにアクセスするためのものです。3 番目の規則はメソッドの呼び出しに関するものですが、括弧とパラメーターは問題とは関係がないため削除しました。元の文法は明らかにこれよりもはるかに大きかったが、これは同じエラー (1 Shift/Reduce conflict) を生成する最小の部分である - 私はそれを独自のパーサー ファイルに分離し、これを検証したので、エラーは何の関係もないその他の記号。

私が見る限り、ここで与えられた文法は明確であり、エラーは発生しません。3 つのルールのいずれかを削除するか、2 番目のルールを

競合はありません。いずれにせよ、この競合が発生する理由と解決方法を明らかにする人が必要です。

(削減された) Pascal から ARM asm にコンパイラを作成しています。私はプロセスの 2 番目のステップにいます。語彙アナライザーを作成した後、Java cupを使用した構文解析に取り組んでいます。

私は自分の文法を書きましたが、5 つの S/R 競合が発生しました。これらはすべて非常に似ています。例：

このセクションの文法:

どうすればこの競合を解消できますか?

ありがとう。

問題の文法の規則を投稿して開始します。

main_interface の後に、コンパイラがトークン T_BEGIN を検出すると、どのバインド ルールに移動するかがわからないことに注意してください。bind_buttons を開始することを意味する場合もあれば、bind_buttons をスキップして T_BEGIN が bind_functions を開始することを意味する場合もあります。

この文法を変更して、この問題が発生しないようにするにはどうすればよいですか?

要件: 端末の追加/削除は許可されていません。コードの記述方法を変更する必要があることをユーザーに伝えることはできません。それを処理するためにルールを変更する必要があります。

私は困惑しています、何かアイデアはありますか？

更新: interface_sections : main_interface bind_buttons bind_functions bind_panel_items ; /* GUI プログラムのコンポーネント */

これにより、バイソンを介して実行すると、同じシフト/削減エラーが発生します。

ただし、正しい軌道に乗っていると思います。T_BUTTONS と T_FUNCTIONS と T_PANEL をルールの先頭に配置する必要があると思います

追加情報：

Packrat パーサーで文字列abcを解析しようとするとします。

ここでは、Packrat パーサーでサポートされている左再帰を使用していますが、なぜ失敗するのかわかりません。パーサーのドキュメントによると P | P が成功した場合、Q は P に等しいため、この場合、次のようにab置き換えた場合と同様に、「a」ではなく「ab」に置き換える必要がありabます。

私はパーサーに取り組んでいて、本当にイライラしています。この言語では、次のような表現を使用できます。

また

最後の空の配列を除いて、ほとんどは正しく解析されます。私のパーサーには次のものがあります。

そして、NewExpressionは次のとおりです。

そして、EmptyArraysは1つ以上の空の中括弧です-EmptyArraysが空の文字列を導出する場合、20のshift/reduce競合が追加されます。

ただし、.infoパーサーのファイルを調べると、次のようになります。

ただし、状態214で左中括弧が表示されている場合は、それをスタックにシフトして、EmptyArrayの解析を続行する必要があります。

NewExpression解析を開始して手荷物から余分なものをすべて取り除くと（たとえば） 、追加の角かっこが正しく解析されるため、何が起こっているのか正確にはわかりません。式、ステートメント、または文法の非終端記号を左中括弧で始めることはできません。特に、if / elseステートメントについて同様のルールがあり、shift / reduceの競合が発生しますが、次のトークンがelseの場合はシフトを選択するためです（この問題は十分に文書化されています）。

何が悪いのか理解するのを手伝ってもらえますか？私は本当にあなたの助けに感謝します、私は問題を理解しようとしている風車に本当に傾いています。

私はsableccで言語パーサーのような単純なJavaを実装しようとしていますが、、およびステートメントを実装するときに常に問題が発生していshift-reduceます。reduce-reduceifwhileblock

たとえば、私は次のことを検討しました。

stmts= stmt*;

stmt= if_stmt| block_stmt| while_stmt;

block_stmt= { stmts }| ;;

while_stmt= while ( predicate ) { stmts }|while ( predicate ) ;

この文法は、例えば、あなたが何かの形をしているときに問題を引き起こします

;パーサーは、 （から）だけを減らすか、 （から）block_stmt完全に減らすかを知ることができません。while (true);while_stmt

私はshift-reduce/reduce-reduce問題の理由をどこでも読んでいて、私はそれらを理解していると思います。しかし、1つはそれらの原因を知ることであり、もう1つはまったく異なることは、私がそれらを回避するように文法を構造化する方法を知ることです。私は非常に異なる方法で文法を実装しようとしましたが、それでも問題が発生します。

ss特定の/問題から実行しようとするのではなく、rrこの種の問題を回避するために、そのようなものに従うための一種のパラダイムが必要だと思いますか？私の問題への取り組み方は完全に間違っているに違いないと思います:(

これらすべての落とし穴に陥ることなく文法をゼロから構築する方法に関するリソースはありますか？この問題に関するリソースは、非常に簡単である（明らかなif then else問題を述べている）か、完全にフラグが立てられた文法である傾向があります。

ネストされたリストを解析するための LALR 文法を作成したいのですが、常にシフト/リデュースの競合が発生します。

type1 アイテムと list2 のリストである list1 があります。

そして、type2 項目のリストである list2 があります。

この文法はシフト/リデュース エラーを生成します。どうすれば回避できますか？

これは具体的なBiglooソースです。

ターミナルは、コメント、改行、テキストチャンク、および空白です。非ターミナルは、input、node-list、node、および text です。

Bigloo は、テキストからテキストチャンクへの reduce ルールについて不平を言っています。

しかし、これは Bigloo の問題ではないと思います。文法の問題のようです。