Здравствуйте, sailichev, Вы писали:

S>Читаю раздел "Парсер и AST".
S>Скажите почему из вашего построенного AST или даже вместо
S>него, просто не набрать дерево выражений using CodeDom?

CodeDom весьма ограничен и не покрывает всех возможностей целевого языка. Собственно, он и для представления дерева C# не подходит так же. Ибо в нем много странных ограничений. Например, нет вообще унарных операторов. В нем есть разделение на Statement и Expression. В Ela — нет. Да и вообще представление операторов в коде-доме для Ela не подходит.
Ну и сам по себе CodeDom не очень удобен в использовании, т.к. универсален. Единственный способ его использования — это расширение CodeDom теми "нодами", которые необходимы для конкретного языка. В случае с Ela это было 50% всего AST.
Но как только вы начинаете его расширять — сразу же теряется все преимущество CodeDom — возможность его трансляции в разные языки, благодаря существованию готовых генераторов. Ну и смысл в нем? Усложнить себе жизнь?

Ну и на уровне AST в Ela есть много маленьких фишек, которые упрощают жизнь компилятору. Например, у каждого элемента AST есть свой тайп-код, представленный в виде энумерации, благодаря которому можно построить эффективный свитч. Используются специальные "хинты" для упрощения анализа — например, хинт Assignable, который позволяет избавиться от нудных проверок на уровне компилятора. Раньше, когда в Ela частичное применение реализовывалось на манер Scala/Nemerle с использованием оператора _, то этот самый оператор так же обрабатывался еще на уровне AST для ускорения компиляции.

А по поводу трансляции в КодеДом — а зачем, собственно?