問題タブ [ply]
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.
python - サブ言語の優先順位
「通常の」表現言語と型注釈の言語の2つのサブ言語で構成される言語のパーサーをPLYで作成しています。問題は、それらがいくつかのトークンを共有し、その優先順位が2つの言語間で異なることです。
たとえば、式言語では(Pythonと同じ意味で)とa | b, c
同等である必要がありますが、型言語では(typeまたはtypeのいずれか、つまりtypeとtypeのメンバーを持つタプル)と同等である必要があります。(a | b), c
a | (b, c)
a
b, c
b
c
実際の問題はそれよりも少し複雑ですが、それでも基本的には同じです。
PLYで一時的に優先順位を変更することは可能でしょうか?そうでない場合、私が適用できる別の解決策はありますか?
python - 暗黙の時間演算子と明示的な時間演算子の解析
ply を使用して LALR パーサーを作成していて、乗算を解析しようとしたときに矛盾に遭遇しました。
完全なパーサーリンクは数千行に及ぶため、ここには含めませんが、簡単なデモを作成しました。
PLY によって報告された shift/reduce の競合や reduce/reduce の競合はありませんが、次の矛盾が発生します。
明示的な時間ルールと暗黙の時間ルールの優先順位が同じであるため、これは奇妙に思えます。しかし、PLY が 'times' トークンに優先順位を割り当て、p_plus ルールで式を減らすことを優先してスタックにシフトするという事実が原因である可能性があると思います。どうすればこれを修正できますか?
編集:より簡単なデモンストレーション。
python - Python PLY - プロダクション ルールをスキップ
PLY を使用する場合、特定のプロダクション ルールをスキップすることはできますか? ( lex が obj.lexer.skip(1) を使用して特定のトークンをスキップできるのと同じ方法で)
例えば:
これはどのように行うことができますか?
python - PLY の文法で 1 つ以上を示す方法はありますか?
私は自然の文法規則を書きたいと思います:
ここで{}
は 1 以上を示します。
たとえば、Lua の文法は同じ構文を使用します。
これは可能ですか?これは文脈自由文法に準拠していますか?
python - 私の文法のあいまいさはどこにありますか?
次のあいまいな文法があります。大文字の規則は単純な語彙トークン用です。
8 つの shift/reduce エラーを受け取ります (Python 2.7 と PLY を使用している場合)。
あいまいさは、「1つ以上」を定義する方法の結果ですか? block : expression | expression block
?
parsing - PLY 文法でこの shift-reduce 競合を修正するにはどうすればよいですか?
私はプログラミング言語の文法を書いていますが、真っ先にシフト/リデュースの問題に直面しています。問題は次の状態にあります。
もう少し詳しく説明する前に、次のことを明確にしたいと思います。
関数を呼び出しているのか、ID を値 (定数または変数など) として使用しているかをプログラムが判断できないため、これはシフト/リデュースですか?
続けて、これを修正することは可能ですか?私の言語では現在、行区切り記号 (C の ';' や Python の '\n' など) を使用していません。パーサーは LALR(1) です。
関数呼び出しと行区切り文字を含む変数を解読する最も効率的な (文法に追加する規則が最も少ない) 方法は何ですか?
編集: これがその状態の先読みです。
python - PLY からパーサーの呼び出し元への解析エラーの報告
そこで、PLY を使用してパーサーを実装しましたが、PLY のすべてのドキュメントでは、エラー メッセージを出力することで解析エラーとトークン化エラーを扱っています。致命的でないエラー報告を実装する最善の方法は、API レベルで、パーサーの呼び出し元に対してどのようなものか疑問に思っています。明らかに、「致命的ではない」制限は、例外が出ていることを意味します — そしてwarnings
、解析エラーのためにモジュールを悪用しているように感じます. 提案?