上記のカテゴリー以外の構文木を目にすることがあるとすれば、それは典型的には合成的なものか短命な構築物だ。項でも型でもなく、シンボルも持たない。リフレクションは、ユニバース経由で構文木を視覚化する方法をいくつか提供する。コードを表示することができる。メソッドを使ってタイプチェッカが用いる生の構文木の内部構造を見ることができる。使ってこの構文木が何を表しているかを見てみよう。逆の方向に行くこともできる。メソッドを用いてコンパイラやタイプチェッカが使っている生の構文木の内部構造を見ることができる。構文木の内部構造が分かった所で、よくある次のステップは情報を抽出することだ。サブクラスを用いた走査パターンマッチングを用いた走査パターンマッチングを用いた走査は最も簡単で一般的な構文木の走査方法だ。典型的にはある構文木の単一のノードの状態を知りたい場合にパターンマッチングを用いた走査を行う。ノードから関数と引数を取得したいとする。普通かなり複雑となることに注意してほしい。用いた走査の方が適しているかもしれない。初めから終わりまで構文木全体を走査する必要がある場合は、パターンマッチ中に現れうる全ての型に対する処理をする必要があるためパターンマッチングを用いた走査は適さない。幅優先探索を用いて渡された構文木の全てのノードを訪れることを保証する。メソッドをオーバーライドする。することで必要なケースだけを処理するカスタムロジックを提供する。ノードだけを探してリストを構築している。メソッドが特別なケースを追加するという形で実現されている。いうパターンにマッチするノードのみに効用がある。追加して、走査を続行する。呼び出していることに注意してほしい。メソッドが確かに呼ばれるようにしている。メソッドを呼び出すことが保証されている。実行時リフレクションを行う際に、構文木を手動で構築する必要は無い。ツールボックスを用いて実行時コンパイルする場合やマクロを用いてコンパイル時リフレクションを行う場合はプログラムを表現する媒体として構文木が使われる。して表現したものを結果として返す。メソッドを用いた構文木の構築が推奨される方法だ。いう式をそれに対応する構文木の表現に変換している。生の構文木の内部構造を出力している。変換されたことに注目してほしい。結果がどこで用いられても意味が変わらないことを保証する。定義するブロックに挿入されたとしてもこのコードの振る舞いには影響しない。1つの構文木へと合成することもできる。