ANTLRを使用する場合と解析ライブラリを使用する場合
私はいつもコンパイラの書き方を学びたいと思っていました-私はANTLRを使うことに決め、現在本を読んでいます（ちなみにとても良いです）
私はこれが非常に新しいので、簡単に行ってください。しかし、要点は、文法を記述し、これをデータ構造（通常はAST）に変換し、これを1回以上歩くことで、実際に「肉」を実行することですあなたがあなたのプログラムにしたいことは何でも。
私の入力「言語」がJSONやXMLのようなものだった場合、つまり、それをpojoのグラフに変換できるライブラリが含まれている可能性があります。これにより、ANTLRなどのコンパイラコンパイラで字句解析や解析を行う必要がなくなりますか？入力が非常に特注である場合は明らかに、独自のレクサー/パーサーを作成する必要がありますが、入力言語がすでに広く使用されている場合は、これをショートカットする必要があります。
ジャクソンを使用してjsonを解析し、POJOに変換して、結果のpojoのコードを実行できると言ってもよろしいでしょうか？ -または、この場合、「適切な」コンパイラコンパイラはいくつかの利点を提供しますか？
編集して（回答に基づいて）追加する
私の質問は少し仮説であったことをおそらく指摘しておくべきでしょう-私はXMLでプログラミング言語を構築しようとはしませんでした！
AST！= Pojo-そして、antlrが提供するツリーウォーカーは、データ構造を「ウォーク」してコードを実行する必要がある場合に、より便利です。
どちらを使用しても、どちらのタスクも実行できます。違いは、それぞれの意味です。必要に応じて画像や図をExcelで描画できますが、その目的のために作成されたもので画像を描画することもできます。
JSONおよびXMLライブラリは、ドキュメントの汎用ロード、ドキュメントからのパーツのプル、またはそれらの構造を別の構造に変換することなどを中心に設計されています。
一方、ANTLRはコンパイラー用のパーサーの生成用に設計されたツールです。そのタスクのニーズに合わせて特別に調整されています。
Xmlまたはjsonパーサーを使用してこれらのいずれかを解析する場合、最終的には、入力をある種のASTに変換して処理できるようにする一連のコードを作成することになります。したがって、これらすべてを記述してデバッグするか、それとも前もってそれを提供するものを使用するかは、あなた次第です。
入力がXMLまたはJSONとしてシリアル化されている場合は、既存のXMLまたはJSONパーサーを使用する必要があります。これにより、最終的にパーサーが正しい可能性が高くなり、他のシステムとの互換性と相互運用性が向上します。 XMLは実際には言語ではなく、共通の構文を共有する新しい言語を定義するためのシステムであることに注意してください。正確でパフォーマンスの高いXMLまたはYAMLパーサーを作成することは非常に簡単です。JSONにもいくつかの小さな落とし穴があります。
パーサーがデータ構造（XMLの場合はDOMなど）を返すと、それをAST表現に変換して、ニーズに合うようにするのはかなり簡単です。独自のパーサーを作成するよりもはるかに簡単です） ASTの構築は、とにかくパーサーの一部になるためです。
私の経験では、データのシリアル化フォーマットは、興味深い言語の主要な入力フォーマットとしてはあまり適していません（ただし、ASTシリアル化）には非常に適している可能性があります）。XMLとJSONは人間が読める形式ですが、それらを手動で書くのは難しいです。たとえば、JSONにはコメントすらなく、XMLには非常に冗長な構文があります。ある程度までは、構文は言語を最終的に作成または破壊するものではありませんが、優れた構文はしばしば意図を明確に伝えます。優れた言語は、セマンティクスと構文の両方で問題領域にうまく対応します。
私は実際にこれを正確に議論している最中です。私の問題は、ユーザーに本当にきれいなYAMLドキュメントを手作業で編集してから、ソフトウェアに再度ロードすることです-CircleCIの機能に似たもの their circle.ymlファイル 。
私たちはJVMを使用しており、SnakeYAMLは非常に優れたYAMLシリアライザー/デシリアライザーなので、プロジェクトに追加して開始するだけで済みますが、ドメインのさまざまなモデルオブジェクトからシリアライザー対応のPOJO（ 'サロゲートのオブジェクト）に戻ります。そして、これは、nullチェックだけを処理するための300行程度の行を含む、かなり悲惨な結果をもたらします（nullチェックの多く、そして私はいくつかを見逃しており、機能を追加するときにそれらを見逃し続けると確信しています）。
ANTLRを使用して構成ドキュメントを真のYAMLドキュメントではなく、YAMLの厳密なサブセットにすると、これらのnullチェックをパーサーに焼き付けることができます。しかし今、私は新しい問題のセットを取得します：私の文法はYAMLの参照を適切に処理しますか？空白処理にバグがありますか（YAMLはpythonプログラミング言語）のような空白に敏感なドキュメント言語です）。
私は本当に引き裂かれました。現在、風が後者を支持しています。というのも、私たちが行っているバグのある検証の量は非常に広範囲になりすぎているからです。
私が尋ねた/自分で持っていたいくつかの質問/考えは合理的に役に立っています：
- シリアライザの使用で発生する具体的な問題は何ですか？
- ターゲット言語はどれくらい複雑ですか？パーサーにはどのような種類の問題がありますか（例：プリプロセッサディレクティブ、コメント（セマンティクス付き）、空白処理）
- 文法、パーサー、ビジターの経験は、洗練された再利用可能なツールの経験、nullチェックの記述の経験、
domainType.x = surrogateType.xではありません。シリアライザを詳しく知ることも役立ちますが、通常、現在の言語/技術スタックから転送することはできません。 - シリアライザとパーサジェネレータの両方をかなり簡単に使い始めることができるため、両方を試すことは不可能ではありません。シリアライザがバックルする前にPOJOクラスがどの程度洗練されているかを確認し、見ている言語のサブセットの単純な文法によってどのような解析ツリーが生成されるかを確認してください。
@Groostav、コメントするのではなく回答するので、もう少し言えます。
興味深い投稿。質問したので、もう少し進歩したので、もう少し見方を変えました。
Id tryは、最初はYAMLやJSONなどの標準を使用すると思います。次に、構成管理システムが実行できることの境界を広げていると感じた場合は、DSLを作成します。
「境界を伸ばす」とはどういう意味ですか？ -まあ、それはプログラミングイディオムをJSONのようなものにしようとするようなものだと思います-たとえば、forループをjsonドキュメントに詰め込もうとすると、おそらくそれが必要なポイントを超えました標準の構成ファイルソリューションではなくDSLである。
「Nullチェック」の観察で2番目のポイントに触れます。 DSLと文法を行う場合、次のようなスキーマ制約を強制できます。
node 'shape' should always have a subnode called 'edges'
文法があなたのためにこれを行うので、これはこの負担の一部からあなたを軽減します-あなたはそれからニースの「ユーザーフレンドリーな」エラーメッセージを取得するためにいくつかの作業をしなければならないかもしれません。
そうは言っても、JSONにはスキーマバリデーターがあり、誰かがYAMLにもスキーマバリデーターを作成したのではないでしょうか。
TL; DRは、科学よりも芸術だと思います...あなたのユースケースでは、あなたが提供した情報で...私はYAMLに固執します。