>Таким образом все-таки получается, что ни один DSL, разработанный при помощи MPS, в реальности не может «выпрыгнуть» за пределы JVM
Это не верно. MPS абсолютно language agnostic. У нас есть, например поддержка javascript. Генерить и расширять можно любой язык, если он реализован в MPS. С Java мы просто больше всего эксперементировали.
>И еще вопрос: не является ли более разумным использование некоего валидатора различных DSL-расширений на предмет неоднозначности синтаксиса, чем использование специального редактора для ввода напрямую синтаксического дерева?
Это плохое решение, по крайней мере для той задачи, которую мы решали, потому что мы не можем совмещать языки друг с другом, как мы могли бы делать с библиотеками.
Он сделан на основе JetBrains IDE Framework. Этот фреймворк был выделен из IntelliJ IDEA, чтобы создавать новые IDE. Кроме MPS, есть наше Ruby IDE, RubyMine, и в ближайшем будущем будут еще IDE.
А если хочется у суммы сабскрипт и суперскрипт поставить? Или хочется в код вставить диаграмму? Все это легко можно реализовать в MPS.
>Если я правильно понимаю, недостаток, например, compile-time преобразования строки (например, в TH или Nemerle) (а уж там можно назадавать любой синтаксис) в том, что это не будет поддерживается IDE?
Да нет, с этим все нормально, проблем нет. Например, IDEA, умеет понимать regexp-ы, когда они находятся в правильном контексте, и подсвечивать синтаксис внутри них.
К сожалению, харизма сейчас коммерческий проект, так что сорцов мы не выложим. Но, вероятно, в ближайшем будущем языки, на которых сделана харизма будут сделаны публично доступными.
Лисп решает проблему парсирования путем существенного ограничения синтаксиса, а это не всегда приемлемо. Например, сделать язык регулярных выражений чисто на s-выражениях, конечно, можно, но использовать это будет тяжело. Другая проблема это то, что лисп динамически типизированный язык, и поэтому сделать мощную IDE поддержку к нему тяжело.
Насчет хаскеля. То, что можно сделать на нем называется internal DSL-ями. Они возможны в принципе на любом языке, но более всего распостранены в питоне, руби итп. При этом подходе, конструкции основного языка используются для создания языка, но опять же, мы ограничены синтаксисом базового языка. Вставить, например, значок суммы, в язык мы не можем.
C немерле все хитрее. В немерле есть макры, но к сожалению, они позволяют добавлять только новые типы выражений, и имеют довольно ограниченный синтаксис. Туда нельзя вставить, например javascript, как мы постоянно делаем в charisma (посылаем javascript на клиент с сервера, чтобы его выполнить там). Вобщем, в немерле все лучше, чем в языках, где обычно делают internal DSL-и, но все равно далеко от идеала.
Это не верно. MPS абсолютно language agnostic. У нас есть, например поддержка javascript. Генерить и расширять можно любой язык, если он реализован в MPS. С Java мы просто больше всего эксперементировали.
>И еще вопрос: не является ли более разумным использование некоего валидатора различных DSL-расширений на предмет неоднозначности синтаксиса, чем использование специального редактора для ввода напрямую синтаксического дерева?
Это плохое решение, по крайней мере для той задачи, которую мы решали, потому что мы не можем совмещать языки друг с другом, как мы могли бы делать с библиотеками.
Например, был код
vector v =…
а мы сгенерировали из него
int _v_x =…
int _v_y =…
Тут, конечно, чтобы все это работало эффективно, придется ввести оптимизации и хитрые преобразования кода, но в принципе это возможно.
Таким образом, кстати, когда-то умел работать Microsoft JVM.
Но, вообще, прикольно. Способ решения проблемы поддержки языко-ориентированного программирования, не таким способом как у нас.
>Если я правильно понимаю, недостаток, например, compile-time преобразования строки (например, в TH или Nemerle) (а уж там можно назадавать любой синтаксис) в том, что это не будет поддерживается IDE?
Да нет, с этим все нормально, проблем нет. Например, IDEA, умеет понимать regexp-ы, когда они находятся в правильном контексте, и подсвечивать синтаксис внутри них.
Насчет хаскеля. То, что можно сделать на нем называется internal DSL-ями. Они возможны в принципе на любом языке, но более всего распостранены в питоне, руби итп. При этом подходе, конструкции основного языка используются для создания языка, но опять же, мы ограничены синтаксисом базового языка. Вставить, например, значок суммы, в язык мы не можем.
C немерле все хитрее. В немерле есть макры, но к сожалению, они позволяют добавлять только новые типы выражений, и имеют довольно ограниченный синтаксис. Туда нельзя вставить, например javascript, как мы постоянно делаем в charisma (посылаем javascript на клиент с сервера, чтобы его выполнить там). Вобщем, в немерле все лучше, чем в языках, где обычно делают internal DSL-и, но все равно далеко от идеала.