問題タブ [peg]

Python Parsimonious Parserを使用して、設計中の単純な言語のインタープリターを構築しようとしています。このチュートリアル ビデオは非常に役に立ちましたが、今は自分のルールに合わせてコードをゆっくりと修正しています。もともと次のように定義されていた割り当てルールに固執しています。

次の文法でルールを少し変更しました。

SET a, 7たとえば、パーサーが同じように評価し、値を name にa = 7バインドしたいと思います。ただし、解析しようとすると、Parsimonious ライブラリから次のエラーが発生します。7a

私は解析/字句解析にかなり慣れていないため、ルールを正しく定義したかどうか完全にはわかりません。解析/字句解析の経験が豊富な人が、ルールを適切に定義し、どこが間違っているかを説明するのを手伝ってくれることを望んでいました. また、倹約的な誤りを私に説明してくれませんか?

まず... PEGを使用して単純な構文の強調表示を実現することは可能でしょうか?

Cスタイルの言語に共通する基本的なことを認識して強調できるようにすることだけを探しています

2番目...これまたは同様の例があれば教えてください

3番目...私がこれを間違った方法で行っており、これを行うためのより一般的で実績のある方法がある場合は、それもお知らせください

オンライン BASIC インタープリター実験用に、4 つの演算子すべてを使用して数式を解析するために、 PEG.jsの文法例を拡張しようとしています。

http://www.dantonag.it/basicjs/basicjs.html

しかし、すべての式が正しく解析されるわけではありません。

これは私のPEG文法です:

2*3+1 (7 を与える) のような式は正しく解析しますが、0 ではなく 2 を与える 2-1-1 のような式は解析しません。

これを改善してデバッグするのを手伝ってもらえますか?

前もって感謝します。

編集：文法に「数」ルールを追加しました。はい、私の文法は出力として解析木に類似した再帰構造を与えます。

私はPEG.jsで遊んで読んでいて、ネイサンズ大学で自分の言語を構築する方法を「説明」するのに良いものを見つけましたが、このステップで立ち往生しています

わかりprimaryません 説明してください

テスト

私の質問は/ "(" comma:comma ")"、エントリに括弧がない場合、その行を削除すると最後のテストが失敗する理由です

以下と照合するための peg.js 文法式を探しています。

• "variable"# 失敗
• "variable."# 失敗
• ""# 失敗
• "variable.variable"＃ Ok
• "variable.variable.variable.variable.variable"＃Ok

期待する入力

• {PATH: "variable.variable"}
• {PATH: "variable.variable.variable.variable.variable"}

Sample.pegjs

式を繰り返す方法がわかりませんが、オプションにすることもできます。

文法：

入力：

質問: 与えられた入力の位置 2 で正しいエラー メッセージはどれですか?

PS

私はパーサーを書き、「b」が位置で期待されるかどうかを考慮に入れる選択（ジレンマ）を持っています。

＃1エラー（「b」、「c」が予想される）は、入力「a b」が予想されることを言いたいのですが、オプションであるため、予想されていないが可能である可能性があります。

可能性が予想と同じかどうかわかりませんか？

#1 と #2 のどちらのエラー メッセージが適切で、正しいですか?

回答ありがとうございます。

PS

最初のケースでは、マーカーをtesting位置の限界として定義します。

オプションのエクスプレッションで制限を移動:

"b" 式は pos_inputPosの上に移動testingし、failure at を追加し_inputPosます。

testing2 番目のケースでは、ブール値フラグとしてマーカーを定義できます。

この場合の "b" 式は、テスト済みであるため、失敗を追加しません (オプションの式の内部)。

何が良くて正しいと思いますか？

1. 特定の位置として定義されたテストと、この位置より上の式 (_inputPos > testing) の場合、失敗が追加されます (オプションの式内であっても)。

2. テストはフラグとして定義され、このフラグが設定されている場合、失敗は考慮されません。オプションの式を実行した後、以前のテスト値 (true または false) を復元します (リセットではありません!)。

また、ルールが失敗しない場合、失敗は考慮されません。解析が失敗した場合にのみ報告されました。

PS

2014 年 1 月 6 日の変更

この質問は、2 つの異なる問題に関連しているため発生しました。

最初の問題:

構文解析式文法 (PEG) は、入力の 3 つのアトミック項目のみを記述します。

• 端子記号
• 非終端記号
• 空の文字列

この文法は字句前処理などの操作を提供しないため、トークンなどの要素を提供しません。

2番目の問題:

文法とは何ですか？同じ入力を受け入れても異なる結果を生成する場合、2 つの文法は等しいと見なすことができますか?

2 つの文法があるとします。

文法1

ルール <- タイプ? 識別子

文法2

ルール <- タイプ識別子 / 識別子

どちらも同じ入力を受け入れますが、(PEG で) 異なる結果を生成します。

文法 1 の結果:

• {タイプ: タイプ、識別子: 識別子}
• {タイプ: null、識別子: 識別子}

文法 2 の結果:

• {タイプ: タイプ、識別子: 識別子}
• {識別子:識別子}

質問:

• 両方の文法は同じですか？
• 文法の最適化を行うのは簡単ですか?

両方の質問に対する私の答えは否定的です。同等ではありません、無痛ではありません。

しかし、あなたは尋ねるかもしれません。「しかし、なぜこれが起こるのですか？」.

私はあなたに答えることができます。「これは問題ではないからです。これは機能です」。

PEG パーサーでは、式は常にこれらの部分から構成されます。

ORDERED_CHOICE => シーケンス => 式

そして、この説明は、「しかし、なぜこれが起こるのか?」という質問に対する私の答えです。

別の問題。

PEG パーサーは WHITESPACES を認識しません。これは、トークンとトークン セパレータがないためです。

この文法を見てください（要するに）：

program <- WITESPACE expr EOF

expr <- ルールX

ruleX <- 'X' ホワイトスペース

ホワイトスペース < ' '?

EOF <- ! .

すべての PEG 文法は、この方法で記述されます。

最初の WHITESPACE はルールの開始時に、他の WHITESPACE は (多くの場合) ルールの最後にあります。

この場合、PEG オプションの WHITESPACE は想定どおりに想定する必要があります。

しかし、ホワイトスペースはスペースだけを意味するわけではありません。より複雑な [\t\n\r] コメントもあるかもしれません。

ただし、エラー メッセージの主なルールは次のとおりです。

期待されるすべての要素を表示できない場合 (または、期待される要素のすべてのセットから少なくとも 1 つを表示できない場合)、この場合は何も表示しないほうが正しいです。

「予期しない」エラーメッセージを表示するには、より正確に必要です。

予想される WHITESPACE を PEG でどのように表示しますか?

• パーサー エラー: WITESPACE が必要です
• パーサー エラー: 予期される ' '、'\t'、'\n' 、'r'

コメントの開始文字はどうですか？また、一部の文法では WHITESPACE の一部である場合もあります。

この場合、WHITESPACE は複雑すぎて表示できないため、エラー メッセージに WHITESPACE を正しく表示できないため、オプションの WHITESPACE は他のすべての潜在的な予想される要素を拒否します。

これは良いことですか、それとも悪いことですか？

これは悪いことではなく、PEG パーサーのこの性質を隠すためにいくつかのトリックが必要だったと思います。

また、私の PEG パーサーでは、オプションの (optional & zero_or_more) 式の最初の位置にある内部式を期待どおりに処理する必要があるとは想定していません。ただし、他のすべての内部 (最初の位置を除く) は、期待どおりに処理する必要があります。

例 1:

この失敗を考慮して、「expected '>'」としてレポートします。これは、「type」をスキップせずに「type」に入り、実際にはオプションの「List」の後で、位置を最初から次の実際の「expected」に移動するためです (すでにテスト位置の外側) 要素。

「リスト」は「テスト」の位置にありました。

内側の式（任意の式の内側）が「制限に収まる」場合、次の位置に継続しない場合、期待される入力として想定されません。

この仮定から主な質問がされています。

PEG パーサーとそのエラー メッセージについて話していることを考慮に入れる必要があります。

Parslet自身の作成者 (このリンクで入手可能)のコード例を出発点として、C に似た構文で記述されたファイルからコメントなしのすべてのテキストを取得するように拡張する必要があります。

提供された例では、C スタイルのコメントを正常に解析でき、これらの領域を通常の行スペースとして扱います。ただし、この単純な例では、入力例のように、ファイルのコメント化されていない領域に「a」文字のみが必要です。

コメントされていないテキストを検出するために使用されるルールは、次のとおりです。

したがって、次のようなより一般的なファイルから他のすべての (コメントされていない) テキストを取得するために、前のルールを一般化する必要があります。

私は構文解析式文法に不慣れで、以前の試行はどちらも成功しませんでした。