あなたは過度に「データ構造とアルゴリズム」の考え方を持っているようです。すべてのツリーが何らかの検索ツリーであるとは限りません。多くの場合、データ構造は、ドメインモデルの側面に対応またはキャプチャするように設計されています。
S式はほぼ正確にバラの木です。(または、むしろ、それらが通常どのように考えられているかをバラの木と言います。ウィキペディアは、それらがバイナリツリーに似ていると言っていますが、「適切な」S式と呼ばれるものは、バラの木とわずかに異なります。)とにかく、それらを抽象構文ツリーの一般的な表現として使用できます。これを行う利点は、「すべての変数を見つける」、「パラメーターを交換する」、「このシンボルの名前を変更する」など、一般的な操作を簡単に記述できることです。また、抽象構文に新しいタイプのノードを追加するために、実際には何も変更する必要がない場合も多いので、拡張可能です。欠点は、実際には何の制約もないため、無意味な記述をアプリオリに妨げないことです。これは、ユーザーが標準の抽象データ型手法を使用して軽減することができますが、変換などの実装者は、入力がデータ型不変式によって構造化されていることを「知っている」としても、非構造化表現を処理する必要があります。もちろん、その確実性が誤っていると(状況が変わった可能性があるため)、エラーは予測不可能で、デバッグが困難になる傾向があります。
実際にData.Tree
は、標準ライブラリのモジュールはローズツリーを提供しますが、Haskellコミュニティでそれを使用する人はほとんどいません。制約を明示的にキャプチャするカスタムデータ型を定義するのは簡単なので、一般的なライブラリ型を使用する理由はほとんどありません。さらに、カスタム型に対してジェネリック操作を実行することに関して、膨大な量の研究と実践が行われており、ジェネリック表現を使用することの多くの利点を排除しています。最後に、Haskellerは、明示的で強制的な制約に非常に賛成する傾向があり、それを取得するために支払う用意があります。
最後の質問に答えるために、多くの場合、ASTの検索は重要ではありません。また、一般にASTは、全体を歩くだけで十分なほど小さいと想定されています。確かに、ASTへの参照を持つ別のデータ構造で定義を収集することは珍しくありません。これは、一種のインデックスと見なすことができます。同様に、一部の最適化パスでは、(通常はローカルで一時的に)インデックスが作成され、操作が簡略化および高速化されます。ASTの構造は入力に対応しているため、「リバランス」などはできません。そのため、AST自体にインデックス付け情報や「検索」に役立つ情報が含まれることは一般的ではありません。