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

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

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

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

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

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

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

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

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

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

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


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

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

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

Какой, интересно? Добавлять собственные узлы?

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

Нет, нельзя. То, что в Ela является Expression, в CodeDom будет Statement. Соответственно, в голом виде я уже не смогу его использовать в виде выражения. В итоге единственный workaround — заворачивать все Statement в CodeStatementExpression, что уже не добавлят удобства.

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

Это единственное преимущество CodeDom. Зачем он еще нужен тогда?

ВВ>>А по поводу трансляции в КодеДом — а зачем, собственно?
S>Затем что становится не нужен свой компилятор.
S>И не нужны маленькие фишки упрощающие ему жизнь. И прочая.
S>И не нужна виртуальная машина.

С чего бы это?
Компилятор нужен. Мало того, что CodeDom не покрывает весь язык, так еще и отсутствует однозначная трансляция между, скажем, функциями в C# и функциями в Ela. В итоге вся работа, которую сейчас выполняет компилятор, свалилась бы на парсер. Как бы мы, интересно, паттерн-матчинг представляли? Генерили бы на КодеДоме кучу иф-ов? А каррированные функции как представить? А прозрачную ленивость? Я уж не говорю о том, что даже код вида "x+y" я в C# не могу отранслировать как "x+y", ибо в C# это вполне конкретная операция, а в Ela — абстрактная, так что придется генерить много кода.
В итоге кода получилось бы *больше*, и этот код занимался бы ручным построением CodeDom-а и выглядел бы, соответствующе.

И главное — что бы это дало? Кроме тормознутого компилятора. Итоговая скорость кода отличалась бы незначительно, ценности для эмбединга никакой и пр.

S>Хотя я может цели всей затеи не так понимаю...
S>А есть спецификация по языку в каком-либо виде?

Спецификации нет, есть книга на английском языке.