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

ВВ>CodeDom весьма ограничен и не покрывает всех возможностей целевого языка. Собственно, он и для представления дерева C# не подходит так же. Ибо в нем много странных ограничений. Например, нет вообще унарных операторов.

Незнаю на счет "весьма" но для любого ограничения есть workaround. готовый.

ВВ>В нем есть разделение на Statement и Expression. В Ela — нет. Да и вообще представление операторов в коде-доме для Ela не подходит.

Можно не обращать внимание на наличие Statement.

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

При чем тут трансляция в разные языки. У вас свой язык. Это не нужно.

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

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

Затем что становится не нужен свой компилятор.
И не нужны маленькие фишки упрощающие ему жизнь. И прочая.
И не нужна виртуальная машина.

Хотя я может цели всей затеи не так понимаю...


А есть спецификация по языку в каком-либо виде?