c - レモンパワーかどうか？

Question

文法パーサーについては、賛否両論があるBisonで「遊んで」いました。

先週、SqLiteサイトでエンジンが別の文法パーサーであることに気付きました: Lemon

薄いドキュメントを読んだ後は素晴らしいですね。
このパーサーについてフィードバックはありますか?

Google やウィキペディアで適切な情報を実際に見ることができない (ほんの数例、同じチュートリアル) あまり人気がないようです。(スタック オーバーフローにはレモンタグはありません [編集: 現在 :P があります])

Answer 1

ファームウェア プロジェクトで Lemon を使用する理由は次のとおりです。

• 生成されるコードのサイズとメモリ フットプリントが小さい。これは、私が見つけた最小のパーサーを生成します (flex、bison、ANTLR、および Lemon によって生成された同様の複雑さのパーサーを比較しました)。
• 組み込みシステムの優れたサポート: Lemon は標準ライブラリに依存せず、外部メモリ管理関数を指定でき、デバッグ ログは削除可能です。
• パブリック ドメイン ライセンス。GPLv2 の下でライセンスされた Lemon の別のフォークがありますが、バイラル ライセンスのため、私たちのニーズには適していません。そこで、最新の sqlite ソースを取得し、それらから Lemon をコンパイルします (2 つのファイルのみで構成されています)。
• プル解析。Flex/Bison の解析コードよりも、コードの理解と維持がより簡単になります。私が賞賛する追加のボーナスとしてのスレッドセーフ。
• トークナイザーとの簡単な統合。私たちのプロジェクトの性質上、可変トークン サイズでバイナリ ストリームをトークン化する必要があります。トークナイザーを実装し、3 つの関数と 1 つのフィードバック コンテキスト変数のみのパーサー API と統合するのは非常に簡単でした。Lemon を re2c および Ragel と統合する方法を調査したところ、実装も非常に簡単であることがわかりました。
• 非常に単純な構文をすばやく習得できます。
• Lemon は、トークナイザーと字句解析器 (パーサー) の開発を明示的に分離しました。私の開発フローは、パーサー文法の設計から始まります。この最初の段階で複数の Parser(...) 呼び出しを使用して、暗黙のトークン シーケンスを使用して複雑なルールをチェックできます。その後、トークナイザーが実装されます。

確かにレモンは特効薬ではなく、適用範囲が限られています。欠点の中で：

• Lemon では、Bison と比較して構文が単純化されているため、より多くのルールを記述する必要があります。繰り返しやオプションがない、ルールごとに 1 つのアクションがあるなどです。
• LALR(1) パーサー制限の完全なセット。
• C言語のみ。

選択する前に、長所と短所を比較検討してください。私はやりました;-)

Answer 2

面白い発見！私は実際にそれを使用したことがないので、解説はドキュメントを読むことに基づいています。

字句解析が構文解析とは別に行われるように再設計することには、メリットがあるようです。特に、複数またはネストされたソースファイルの処理などの操作を簡素化する可能性があります。Lexベースのyywrap()メカニズムは理想的とは言えません。すべてのグローバル変数を回避し、慎重なメモリ割り当てと割り当て解除の制御を優先する必要があります（アロケータと割り当て解除の選択が非常に役立ちます-少なくとも、メモリ割り当てが常に問題となる私が働いている環境では） 。

ルールがどのように編成され、端末がどのように識別されるかを再考することは良い考えです。

全体として、それはバイソンのよく考えられた再設計のように見えます。

参照されているWebページによるとパブリックドメインです。