Lin記述子ファイルパーサー

Question

私は、Lin Descriptor Fileの解析に使用できるPCアプリケーションの開発の一環として、可能なパーサーについて研究しています。現在のパーサーアプリケーションは、flex-bison解析手法に基づいています。現在、パーサーを再設計する必要があります。なぜなら、現在のパーサーは特定のエラーを検出できないからです。

私はこれまで正規表現（Regex：https://en.wikipedia.org/wiki/Regular_expression）の解析にRagelパーサ（https://en.wikipedia.org/wiki/Ragel）を使用していましたが、非常に便利でした。

しかし、現在の複雑さがLDF-fileの場合、LDF-fileを解析するための最良の方法はRagel（ホスト言語としてC++を使用）であるかどうかはわかりません。その理由は、LDF-fileには固定または固定ではなく、ベンダーごとに異なるデータが多数存在するためです。 LDFフィールドには、ファイル内のエラーを検出するための他のフィールドへの参照が保持されている必要があります。 Ragelは構文解析用の構造が固定されている場合に適しています（Regexパーサの開発中に見つけたもの）

すでにこのようなプロジェクトに取り組んでいる方は、Lin Descriptorに適したパーサーファイル。林記述ファイルを

例：http://microchipdeveloper.com/lin:protocol-app-ldf

Answer 1

あなたはLALR（1）パーサはあなたの構文解析の問題に十分でないと感じた場合、有限オートマトンが良いだろうということは不可能です。 FAは厳密にはパワフルではありません。

あなたが実装したい小切手の性質について多くのことを知らずに、適切な戦略がファイルをいくつかの単純な階層的なデータ構造（つまり、通常はASTで文献を解析）、フレックス/バイソン文法を使用して結果のデータ構造を歩き、必要と思われるセマンティックチェックを実行します。

解析中にセマンティックチェックを実行しようとすると、通常、複雑すぎる、ひどく因果関係があり解読できない解決につながります。これは、バイソンツールの問題ではなく、むしろ、私たちが懸念の分離の重要性について学んだことを考慮に入れていない特定のスタイルを使用していることによるものです。

既存の文法をリファクタリングして、 "単なる文法"（つまり、必要な意味表現を生成する）をリファクタリングすることは、他のパーサージェネレータで再実装するよりはるかに簡単な作業ですどんな場合でも実質的な利点を提供するため）。

パーサージェネレータを放棄する誘惑には、よりモジュール化されていないソリューションに賛成する必要があります。何かを構築するのに成功する可能性がありますが、結果は現在のものよりも維持管理が難しく、 。