на чём реализовать DSL?

эклипсовский xtext ?

кстати, интересный блог, спасибо

> эклипсовский xtext

Так-то оно так, но непонятно, что там с отладкой DSL-ей... есть инфа об этом?

Тебе првда все равно что из выбирать из списка? И на язык реализации c/c++, java, CL(о, ужас :)) пофиг, ты знаешь их все?

lex+yacc - к этому как-то слабо применимо «одной кнопкой перегенерировать все инструменты», много чего надстроить поверх потребуется.

Все что вы назвали есть в MPS. Причем возможность добавлять новые синтаксические конструкции нормально может существовать только в системах типа Jetbrains MPS, а таких систем всего одна - Jetbrains MPS, таким образом вопросов в выборе возникнуть не должно.

Крутые требования. Думаю, lex/yacc можно вычеркнуть из-за пункта 2.

> Тебе правда все равно что из выбирать из списка?

Сейчас для меня важно найти наиболее подходящий инструмент. Я писал немного на CL, много на C++, на яве тоже писал. Могу освоить что-то новое, если потребуется. Лишь бы результат был хороший.

> возможность добавлять новые синтаксические конструкции нормально может существовать только в системах типа Jetbrains MPS, а таких систем всего одна - Jetbrains MPS

Почему? Аргументируйте. Вам это может быть очевидно, но у меня-то опыта нет.

Вам же не dsl отлаживать, а результирующий код, насколько я понял из требований? Отладка грамматики, кстати, ЕМНИП, есть у antlr

Не слушайте его. MPS - это секта типа баптистов. Благие намерения, а по сути - просто ханжи и извращенцы.

>> возможность добавлять новые синтаксические конструкции нормально может существовать только в системах типа Jetbrains MPS, а таких систем всего одна - Jetbrains MPS

Почему? Аргументируйте

А ты не мог бы аргументировать саму необходимость добавлять синтаксические конструкции? Потому что это сразу усложняет задачу на порядок.

> MPS - это секта типа баптистов. Благие намерения, а по сути - просто ханжи и извращенцы.

+1

Хочется отлаживать не парсер, и не результирующий код, а непосредственно программу на DSL. Чтобы пользователь написанную им программу на DSL-е мог отладить, не являясь при этом знатоком языка реализации.

CL - выбор СL явно преполагает что ты его уже неплохо знаешь или собираешься развивать и поддерживать свой DSL еще лет 10. С динамичтностью проблем не будет. Возможности отладчика зависят от того как будешь транслировать. Scheme - имеет некоторые решения по разбору и трансляции, но у начинающих из них часто получается одноразовая каша. Почему не Racket? Clojure - ну кроме тесной интеграции с явой и несколько порезаных относительно CL возможностей, ничего интересног там для DSL вобще нет.

> А ты не мог бы аргументировать саму необходимость добавлять синтаксические конструкции? Потому что это сразу усложняет задачу на порядок.

Пользователи будут разные. Кто-то доволен возможностями DSL, которые предлагаются по умолчанию, языков никаких (кроме этого DSL) не знает, и единственное, что ему нужно — это отладка.

Другой пользователь захочет добавить в DSL новую процедуру обработки данных. При этом, у самого DSL нет возможности определять новуе процедуры (и не будет, т.к. DSL сочинил не я). Пользователь захочет определить свою процедуру вне DSL (на языке реализации) и ввести её в DSL под видом «ключевого слова».

Вот отсюда и появилось второе требование.

Подразумевается, что с п.1 у lex/yacc всё в порядке? Если да, то как?

> Другой пользователь захочет добавить в DSL новую процедуру обработки данных. При этом, у самого DSL нет возможности определять новуе процедуры (и не будет, т.к. DSL сочинил не я).

Если реализации DSL еще нет даже близко, почему бы просто не расширить его понятием внешней процедуры или определением процедур на самом DSL?

Вот отсюда и появилось второе требование.

Я не вижу, как «возможность добавлять новую процедуру обработки данных» влечет за собой добавление или переопределение ключевых слов, но, если ты понимаешь последствия, тогда ОК.

> Если реализации DSL еще нет даже близко, почему бы просто не расширить его понятием внешней процедуры или определением процедур на самом DSL?

Реализация есть, но она стара и негодна. Надо её переписать, что я и намереваюсь сделать.

Я не вижу, как «возможность добавлять новую процедуру обработки данных» влечет за собой добавление или переопределение ключевых слов

Про переопределение: например, в языке есть прекрасный «оператор» под названием Compute, имплементация которого занимает много тысяч строк. Какой-нибудь пользователь захочет сделать свой «Compute» иначе, оставаясь при этом в рамках изначального DSL.

> Подразумевается, что с п.1 у lex/yacc всё в порядке? Если да, то как?

С пунктом 1 у lex/yacc просто никак (это генератор парсеров, а не отладчиков), но это не мешает использовать lex/yacc для твоей задачи. Вот пункт 2 - да, мешает.

Я лично подозреваю, что тебе нужно еще раз обдумать задачу - в том виде, как ты ее ставишь (с автоматической генерацией отладчика), решить ее могут мощные фреймворки, а они привязаны к вещам типа Eclipse или IDEa. С другой стороны, Транслятор, AST-интерпретатор и даже отладчик несложного LL-языка - задача нетривиальная, но без принципиальных сложностей, _если_ не пытаться реализовать изменяемый пользователем синтаксис.

Почему не подойдет eDSL?

В области DSL я начинающий, но практических требований это не отменяет. Чтобы сделать хорошо, надо как минимум (1) выбрать платформу, исходя из практических требований и (2) посмотреть на примеры проектов, успешно сделанных на этой платформе.

Допустим, CL или Racket. На какие проекты посмотреть, чтобы впечатлиться?

> Про переопределение: например, в языке есть прекрасный «оператор» под названием Compute, имплементация которого занимает много тысяч строк. Какой-нибудь пользователь захочет сделать свой «Compute» иначе, оставаясь при этом в рамках изначального DSL.

Из того, что ты сказал, кажется, что Compute - это внешняя процедура. Если для ее реализации нужно много тысяч строк кода (на чем?), то я не очень понимаю, чем тебе поможет изменение синтаксиса.

Пойми - если ты хочешь дать пользователю возможность менять синтаксис, тебе придется делать либо полноценную макросистему в духе Camlp4, либо среду метапрограммирования в духе того же xText. У тебя точно нет других идей?

>Почему? Аргументируйте. Вам это может быть очевидно, но у меня-то опыта нет.

Да потому что даже в самом простом случае, новые конструкции могут вносить неоднозначность в грамматику, вылавливать и идентифицировать которую при хоть соклько-то нетрививальном языке будет просто АД. Ну и потом это единственный фреймоврк которые предлагает готовое решение для создание DSL + IDE к нему с дебаггером, генератором, статическим анализом и прочее прочее, к чему остальные даже близко не подошли.

> MPS - это секта типа баптистов. Благие намерения, а по сути - просто ханжи и извращенцы.

Ко всему новому так относятся.

> Ну и потом это единственный фреймоврк которые предлагает готовое решение для создание DSL + IDE к нему с дебаггером, генератором, статическим анализом и прочее прочее, к чему остальные даже близко не подошли.

xText к этому как минимум подошел.

> Ко всему новому так относятся.

ему уже лет 8

>ему уже лет 8

Концепция новая.

> Из того, что ты сказал, кажется, что Compute - это внешняя процедура. Если для ее реализации нужно много тысяч строк кода (на чем?), то я не очень понимаю, чем тебе поможет изменение синтаксиса.

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

Про Camlp4 я не знал, спасибо. Посмотрю. У него есть средства для отладки программ, написанных на сделанном DSL? Аналогичный вопрос про xText.

>xText к этому как минимум подошел.

К сожалению, и близко нет. Дебаггер? Статический анализ кода? Рефакторинг? «умный» интеллисенс? Да и библиотека генерации там _на порядок_ хуже чем в MPS. Сколько-то сложные языки в нем описывать не проще чем на голом ANTLRе.

> Сейчас для меня важно найти наиболее подходящий инструмент.

Тут нет критериев подходящисти.

MPS, например, инструментальный пакет, который уже готовый отладчик, подсветку, типа ide. В минусах DSL будет прибит предметной области MPS, что не всегда нравиься.

CL с другой стороны - среда и язык для создания таких вещей как MPS. И в этом смысле с ним несколько проще.

Если знаешь CL то берешь и делаешь. Никаких особенных трудностей здесь нет. Это вполне реальная для CL задачка.

Embedded Domain-Specific Language? Видимо, это не годится потому, что DSL уже придуман, один раз реализован (без возможностей отладки и пр.), и на нём написано много кода. Короче, DSL уже есть как данность, и он не Embedded, т.к. куда-либо его «embed» не представляется возможным.

Задача: реализовать его на практике.

DSL уже придуман, один раз реализован (без возможностей отладки и пр.), и на нём написано много кода

Ну вот, как всегда появляются нюансы.

Сколько пользователей уже существующего DSL? Сколько строчек кода? Как насчет варианта просто трансформировать существующий код в другое представление, более удобное в поддержке?

> Как насчет варианта просто трансформировать существующий код в другое представление, более удобное в поддержке?

Это обсуждаемый вариант, но говорить о нём преждевременно, пока не ясна ситуация с заменой только реализации. Нужны сильные аргументы, чтобы заставить пользователей мигрировать на новый язык.

Новому? Что там «новое», простите? МПС продвигают уже не первый год, а все никак. Неудобство работы с этим комбайном нивелирует все плюшки, которые дает dsl. А новых концепций там и вовсе нет.
Хотя сам по себе функционал там обширен, нельзя ни признать.

а можно пример задачи, для чего вам это надо?

Допустим, неоднозначностей в новых конструкциях не будет (возможно, я переборщил с описанием — на самом деле, в язык будут вводиться/модифицироваться только переменные + вызовы внешних процедур).

Комплишены, рефакторинг и прочий статический анализ в данной задаче также не нужны.

Отладчик нужен, да. Охотно верю, что xText это не умеет, но из этого ещё не следует, что MPS — единственное подходящее решение :) Хочется объективно рассмотреть все имеющиеся инструменты, а потом уже делать выводы.

>А новых концепций там и вовсе нет.

Есть. Новый подход к описанию синтаксиса языка, генераторов, code flow, и так далее. Это действительно круто. Но, это не значит что я фанат этого инструмента - я вообще считаю что такая вариативность синтаксиса - излишня, и вообще за предметно ориентированные языки _моделирования_ а не программирования :)

> Будем пока считать, что продвинутым пользователям нужно модифицировать внешние процедуры, и добавлять свои. Какие инструменты годятся с такой формулировкой?

Тогда любые, хоть recursive descent вручную (всё равно средство добавления внешних процедур придется писать специфическое). Автоматически генерируемый отладчик, похоже, есть только в MPS, но ты не хочешь прибивать себя гвоздями к IDEa.

Про Camlp4 я не знал, спасибо. Посмотрю. У него есть средства для отладки программ, написанных на сделанном DSL? Аналогичный вопрос про xText.

Оба раза «нет».

то, о чем вы говорите - это не концепция :) мы же не на рекламной акции

>в язык будут вводиться/модифицироваться только переменные + вызовы внешних процедур).

Ну так это не расширение языка. Вроде заведение новых переменных в языке не является его расширением :)

xText хорош, если у вас простой декларотивный язык. ну, отладку предтся ручками реализовывать, но если разбираться в платформе Eclipse это не очень страшно.

>то, о чем вы говорите - это не концепция :)

Концепция - это Language Workbench? Да, не они предумали но они ее первые нормально реализовали. И то что я привел - это реально новые идеи, а не рекалма.

Попробуй Racket - там очень много батареек вложено как раз для разработки DSL/eDSL, так же много и готовых примеров (см. разные «языки», идущие с Racket - это по сути и есть eDSL-и).

Другой вариант - Bigloo, там тоже очень много готового, и для парсинга и для кодогенерации.

Сам я был бы рад пользоваться чем либо из этого, но на практике вынужен писать DSL-и на шарпе.

У MPS есть одна особенность, с одной стороны весьма интересная, с другой ограничивающая возможные применения - это его непонятный для непосвященных, странным образом себя ведущий нетекстовый редактор.

Вот, а то с тем же успехом можно сказать, что микрософт придумали оконные системы :) У МПС оригинального только реализация, чисто техническая сторона. И она хромает с некоторых точек зрения.

> Автоматически генерируемый отладчик, похоже, есть только в MPS, но ты не хочешь прибивать себя гвоздями к IDEa.

Да нет, я в принципе не против прибивания гвоздями к IDEA. Единственное требование — кроссплатформенность, и IDEA ему удовлетворяет. И бесплатная к тому же. Но хочется узнать и про альтернативы, типа CL, Racket, может кто-то ещё назовёт.

Автоматическая генерация отладочной инфы для DSL есть даже в pfront. Он правда во всем остальном на редкость придурочный.

В Racket же отладка на высшем уровне, с визуализацией всего чего хочешь.

У MPS оригинальный весьма редактор. Хотел бы я такое же для XML. Ничего подобного раньше не встречал.

> Да нет, я в принципе не против прибивания гвоздями к IDEA.

Думаю, ты бы успел написать на каком-нибудь C++/Qt автономный отладчик за время, которое будешь разбираться с MPS, но это дело твое.

> Автоматическая генерация отладочной инфы для DSL

Что такое «отладочная инфа для DSL» - что-то вроде DWARF? Это не отладчик.

Это символы, строки, блоки кода - .pdb/.mdb в .NET, аналог Dwarf. Соответственно можно использовать свой любимый отладчик.

В Racket отладчик свой, не зависимый от языка.