問題タブ [tinypg]

GOLD メタ構文(RegExp + BNF) にあるこれらの BNF 文法をTinyPG で使用するにはどうすればよいですか? 私は BNF を初めて使用するので、BNF を EBNF に変換するには、どのような種類の変換を行う必要がありますか?

RegExp + BNFである GOLD 文法と比較して、TinyPG は RegExp + EBNFを必要とするため、かなり単純なはずだと思います。

また、利用可能な言語の TinyPG ソース コードはありますか?

TinyPG とは何ですか? また、どのように機能しますか? 「コンパイラ-コンパイラ」であることは知っていますが、C# で独自のコンパイラを作成するにはどうすればよいですか?

ラムダ計算を解析するために、LL1 パーサー ジェネレーターであるTinyPGを使用しています。(a b)関数の適用などを解析するルールを書こうとしてい(a b c)ます。

これまでのところ、次のルールがあります (少し単純化されています)。

しかし、それは、左括弧の後と右括弧の前にスペースがある用語を解析できません: ( a b ). 次のように、開始ブラケットの後にスペースを許可できます。

しかし、閉じ括弧の前にスペースを許可するように設定するのに問題があります。私はこれを思いついたが、うまくいくようだ：

しかし、面倒で再帰的であるため、ノードの読み取りとコンパイルが難しくなります。これを解析するための非再帰的または少なくともより簡単な方法はありますか?

私が設計していない単純な言語を解析する必要があるため、言語を変更することはできません。C# で結果が必要なので、使いやすく、パーサーを実行するために外部ライブラリを必要としないので、TinyPGを使用しています。

言語でこの構造に出くわすまで、物事はかなりうまくいっていました。(これは単純化されたバージョンですが、問題を示しています):

結果のパーサーはこれを解析できません:

END をキーワードIDENTIFIERとして適切にではなく、貪欲に lexes するためです。END

だから、ここに私の質問があります：

1. この文法は LL(1) 解析に対してあいまいですか、それとも間違っていますか? それともTinyPGのバグですか？

2. TinyPG例の行を適切に解析するように文法を再設計する方法はありますか?

3. C#コードを出力し、追加のライブラリを必要としない単純なパーサーに関する他の提案はありますか? LLLPGとを見てきましたがANTLR4、 よりもはるかに面倒TinyPGでした。

私が設計していない単純な独自言語を解析する必要があるため、言語を変更することはできません。C# で結果が必要なので、使いやすく、パーサーを実行するために外部ライブラリを必要としない TinyPG を使用しています。TinyPG は単純な LL(1) パーサーを生成します。

私が現在抱えている問題は、言語がファイルをセクションに分割する方法に関連しています。さまざまな種類の変数、初期値の設定、方程式の定義などのセクションがあります。変数を宣言するセクションだけを気にするので、残りは無視したいと思います。他のセクションのすべてのルールを知っているわけではなく、それらを理解する必要はありません。それらはコメントとして扱われる場合があります。

コード例を次に示します。

PARAMETER セクションと SET セクションは気にしますが、EQUATION セクションは気にしません。ご覧のとおり、問題はこれらのセクションに END マーカーがないことです。したがって、別のキーワードを取得したときにセクションが終了するが、新しいキーワードが新しいセクションを開始する可能性があることを文法に伝える方法がわかりません。私の試みでは、新しいセクションの開始キーワードが消費されて、古いセクションが閉じられます。

ここにリストした以外にも多くのセクションがあり、重要なものもあれば、そうでないものもあります。ステートメントの最後にセミコロンがない「PARAMETER のように見える」と、セミコロンがある「EQUATION のように見える」の 2 つのタイプに分類されるようです。この言語では、大文字と小文字や空白は区別されません。セクションの順序は任意です。(例: SET、EQUATION、PARAMETER) コメント以外はすべて 1 行で記述できます。

現在、正規表現を使用して興味のあるセクションを見つけ、それらをパーサーに渡すだけでこれを回避していますが、すべての場合に機能する正規表現を思い付くのにも苦労していますが、コメント内のキーワードを誤って拾うことはありません。問題を解決するためにこの回避策を拡張することになるかもしれませんが、文法で直接問題を解決する方がよいでしょう。これは LL(1) 言語ではない可能性があります。