コンパイラの抽象構文ツリーを理解する
以下の問題を回答に添付しました。私の問題はそれが理解できないことです。最初の式を導出することにより、解析ツリーとETF文法について詳細に全体的な説明を提供できますか？
最初の式a+b/c+dを説明してみてください。難しいことではないと思いますが、これを理解するための適切なリソースを見つけることができませんでした。 ETF文法を説明するリソースも提供できますか？説明したくない場合は、少なくともこれを理解するためのリソースを指摘できればいいでしょう。
抽象構文ツリー は、構造を使用して括弧やその他のテキスト表現の詳細を削除するデータ構造です。
演算子の優先順位 （テキスト表現の重要な機能）は、ASTではツリーの構造にエンコードされます。一方、テキスト形式では、演算子の優先順位は、演算子の優先順位ルールと括弧を使用してオーバーライドされます（またはさらに強調するために）標準ルール。
ASTからテキスト表現に変換することは、コード生成の一種です。
単純に、それらを排除する適切な最適化、またはテキスト文法の演算子の優先順位の理解がない場合、これらのバイナリ演算はすべてテキストで()に囲まれて生成されます。
したがって、最初のツリーの例では、単純にテキストで生成されます。
( ( a + ( b / c ) ) + d )
一般的な演算子の優先順位に合わせて最適化すると、すべての括弧を削除できます。
束の中で最も興味深いのは、左下です。これは、除去できないテキスト表現に()が必要なためです。ただし、ツリー形式のASTでは、通常どおり、()は不要です。テキスト表現の()による優先のオーバーライドにより、乗算がツリーの構造に固有で暗黙的なものになる前に加算が行われるため、ASTフォームで明示的に()を使用する必要はありません。
文法を（テキストとして）エンコードする一般的な方法である （E）BNF を見てください。 [〜＃〜] antlr [〜＃〜] も参照してください LL（*） 文法を解析できるパーサージェネレーターツールです（-よりも強力です- LALR（1） およびLL（k）文法。
ETF文法は、演算子の優先順位のレベルに制限があり、特に、加算よりも優先順位が低く、優先順位をオーバーライド（または強調）できる()に対応するのに十分なレベルの優先順位がある、文法の多少制限された表現です。 ETF、expression、term、factorは、実質的に3つのレベルです。 Fが( E )を許可することに注意してください。つまり、F（優先順位が高い）が許可され、()で囲まれたE（優先順位が低い）は、包含されている式に対する包含された式の優先順位を()でオーバーライド（例：上げる）できるようにします。
また、構文解析ツリーと抽象構文ツリーを区別しましょう。 Parse Trees（aka concrete syntax trees） 入力構文に対応するより多くのノード、つまり、言語の特定の入力テキストの文法で実際に認識された生成を明示します。したがって、左下の式の場合、ツリーの()演算子のすぐ上に+ノードがあります（他のすべてのものについては言うまでもありません）。対照的に、AST形式では、これらのテキストの詳細は抑制されます。