問題タブ [lemon]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
184 参照

c - 条件文をレモンでパースする

次のスクリプトを解析したい

解析できる最初の行str="HELLO"で、変数は使用のために保存されます。スクリプトを実行できる

出力を取得しますHELLO

しかし、条件付きの if ステートメントはまだ実行できません。では、条件文をどうしようか迷っています。このレモン文法を定義してみました

expr(A) ::= IF '[' expr(B) EQEQ expr(C) '];then' expr(C) 'fi'.

しかし、引用符が不正な文字であるというエラーが表示されます。なので、if文の文法の書き方がわかりません。私の文法全体は

のメインループは次のようになります。

問題は、if ステートメントの文法で角括弧を宣言する方法がわからないことです。ifステートメントは、条件と条件が真の場合に評価される式の「複合」ステートメントであるため、少なくとも2つまたは3つの式が含まれます。私はすでに動作する等式を定義しました:

expr(A) ::= expr(B) EQEQ expr(C). {if(B==C) {A=1;} else A=0;}

しかし、引用符で角括弧を作成しようとすると、lemon からコンパイラ エラーが発生します。引用符を使用しないと、別のエラーが発生します。

Illegal character on RHS of rule: "[".

宣言しようとすると、上記のエラーが発生します。

expr(A) ::= IF [ expr(B) EQEQ expr(C) ];then expr(C) 'fi'.

0 投票する
2 に答える
299 参照

c++ - Lemon Parser は物事をスキップします (または私の誤解)

詳細情報を更新

Lemon を使用して要素の単純な配列を解析する際に問題が発生しています。誰かが私を啓発できますか??

この文字列 "[0 0 612 792][100 200]" を mygrammar 定義で解析しようとしていますが、パーサーは常に最初の配列要素をスキップし、最後の要素を複製します...任意のアイデア??

文法ファイルは

re2c を使用してトークンを取得し、各トークンのパーサーを呼び出すコードは次のとおりです。

入力文字列 "[ 0 -100 612 792][100 200]" の場合、出力は次のようになります。

お気づきのとおり、最初の要素は表示されず、最後の要素が複製されています。

レモンからの文法は次のとおりです。

サンプル文字列の出力トレースは次のとおりです。

私はこのエラーで立ち往生しています。これは、理解できない概念エラーであると確信しています。どんな助けでも大歓迎です。

ありがとう

0 投票する
1 に答える
267 参照

c - レモンパーサーの競合を取得する

javascript に似た言語用に、lemon を使用して単純なパーサーを作成しようとしています。競合エラーを解決できません。解決できない問題だと思います。

競合は、次の文法の間にあります。

1 つ目は代入ステートメントを含むステートメント ブロックで、2 つ目はオブジェクトを定義する式ステートメントです。

それらの両方を解析する文法は、競合を引き起こします。最小限のコードは次のとおりです。

out ファイルには次のように表示されます。

これを解決する方法についての提案は、ありがたく受け入れられます。ありがとう。

0 投票する
2 に答える
1343 参照

parsing - LALR 文法におけるシフト還元の競合を克服する方法

正と負の小数を解析しようとしています。

最初の 2 つのルールを含めるとシフト/リデュースの競合が発生しますが、競合が発生しないように文法を記述する方法がわかりません。私はレモンパーサーを使用しています。

編集: .out ファイルからの競合

編集 2: 問題を引き起こす最小限の文法

0 投票する
1 に答える
37 参照

parsing - パーサーが事前にトークンを先読みしていると仮定する必要がありますか?

何年も離れてからレクサーとパーサーに戻ると、コンテキストの目的で、状態変更の概念に困惑していることに気づきます。私はレモンをパーサーとして使用し、独自のレクサーをまとめています。

次のような入力例を見てみましょう。

したがって、「syscon:」と「sysmemremap:」は同じように見えますが、一方は GROUPNAME で、もう一方は REGISTERNAME です。[グループ] と [レジスタ] の間には、各トークンが実際に何であるかを決定するコンテキストの変更があります。

その文脈上の変更を行うのに最適な位置にあるのはパーサーですか? パーサーにはセクション文法がなく、あるセットの文法はあるセットの状況に適用され、別のセットの文法は別のセットに適用されるため、モードがそうすべきです。

編集:ウィキペディアで問題を要約した「レクサーハック」のエントリを見つけました:

コンテキストを追加しないと、レクサーは型識別子を他の識別子と区別できません。これは、すべての識別子が同じ形式であるためです。.... 一般に、解決策はセマンティック シンボル テーブルからレクサーに情報を戻すことで構成されます。つまり、レクサーからパーサーへの純粋な一方向のパイプラインとして機能するのではなく、セマンティック分析からレクサーに戻るバックチャネルがあります。

パーサーのトークンの事前読み取りについて何を推測できますか? パーサーが先に進み、より良い一致を行うためにより多くのトークンを読み取っている場合 (少なくともある程度はそうなると思います)、パーサーの状態変更がレクサーにとって遅すぎるという状況に陥る可能性があります。それはすでにそのトークンに会って処理しました!

それとも私はこれを考えすぎていますか?

0 投票する
1 に答える
231 参照

parsing - レモンパーサーはエラーを減らします

英文の数字を解析する文法を書こうとしていますが、999 までは正常に解析できます。千の位をサポートするロジックを追加すると、reduce解析の競合が発生し、苦労しています。何が原因かを理解することです。

レモンによって生成された parser.out ファイルの一部を添付しました。誰かがこの問題に光を当ててくれることを願っています。文法の大部分も含めて、1 行目より下のすべてが単独で機能しますが、1 行目より上の数千のロジックを追加すると、問題が発生し始めます。

私の考えでは、「ぶら下がっているelse」に似た問題に遭遇していますが、セパレーターを使用しています。ただし、それは通常shift-reduceエラーとして現れますが、私はただのエラーのように見えreduceます。Lemon のドキュメントは少しまばらで、parser.out ファイルの内容の読み方が正確にはわかりません。たとえば、行HYPHEN reduce 15 ** Parsing conflict **の偶数は何15を指していますか?

どんな助けでも大歓迎です!


私の文法ファイルの一部:

エラーのある parser.out の部分: