LINUX.ORG.RU

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


1

5

Имеется DSL, простой императивный язык с LL(1) грамматикой. Задача: реализовать его на практике.

Я читал что-то про lex+yacc, CL/Scheme/Clojure, MPS, ANTLDR, LLVM, xText и Meta Platform им. Луговского. Но никакого опыта с созданием DSL не имел.

Кроме собственно компилятора/интерпретатора, хочется получить:

  1. Что-то похожее на отладчик. Не грамматики, а собственно языка. Пройти программу по шагам, посмотреть переменные, всё такое.
  2. Динамичность для пользователя. Чтобы он мог, например, добавить в язык новое ключевое слово, или переопределить существующее, и одной кнопкой перегенерировать все инструменты.

Технологических ограничений нет, кроме того, что нужна кроссплатформенность (Windows+Linux).

Какое средство наиболее подходит? Будет интересно узнать, кто чем пользовался при создании DSL. Спасибо.


Ответ на: комментарий от anonymous

Racket посмотрю, спасибо.

Что касается Bigloo, то как я это не средство создания DSL-ей, а пример того, как с нуля (на голом C) сделать все инструменты для нужного тебе языка :) Это как раз то, чего я пытаюсь избежать, взяв готовое решение.

ringill
() автор топика
Ответ на: комментарий от bik

> У МПС оригинального только реализация

Еще раз - нет, у них оригинальна концепция редактора, генерации, и много чего еще. Они _другие_, принципиально другие.

theos ★★★
()
Ответ на: комментарий от ringill

Не, Bigloo - это такой мощнейший комбайн для метапрограммирования. Там есть CL-подобные макросы, есть несколько разных библиотек для реализации парсеров, несколько библиотек для pattern matching - а большего и не нужно, DSL на такой основе можно лепить вообще не включая мозг.

anonymous
()
Ответ на: комментарий от anonymous

Хорошо, но в таком случае как там с п.1 (пройти myprogram.dsl по шагам, посмотреть переменные, всё такое)?

ringill
() автор топика
Ответ на: комментарий от anonymous

>У MPS есть одна особенность, с одной стороны весьма интересная, с другой ограничивающая возможные применения

Да, с этим никто и не спорит.

theos ★★★
()
Ответ на: комментарий от ringill

Для этого можно родным дебаггером самого bigloo пользоваться.

anonymous
()
Ответ на: комментарий от ringill

> Язык называется СЛОН, он очень стар и довольно специфичен. ftp://quasar.ipa.nw.ru/incoming/era/era_manual.ps

/me читает и плачет от ностальгии. Там среда в духе TurboC/Borland C++, да? И ты это сокровище хочешь прибить гвоздями к MPS? %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Там среда в духе TurboC/Borland C++, да?

Там сейчас в качестве «среды» практически голый редактор. Если я сделаю отладчик для этого языка, равный по возможностям TurboC, я буду вполне счастлив.

ringill
() автор топика

>Динамичность для пользователя. Чтобы он мог, например, добавить в язык новое ключевое слово, или переопределить существующее, и одной кнопкой перегенерировать все инструменты.

И тут врывается http://scg.unibe.ch/research/helvetia

yoghurt ★★★★★
()
Ответ на: комментарий от tailgunner

Вот-вот. Винтажные DSL надо и реализовывать винтажными методами. Парсер и кодогенератор на Фортране, отладка в стековой VM, и тому подобная прелесть.

anonymous
()
Ответ на: комментарий от ringill

> Если я сделаю отладчик для этого языка, равный по возможностям TurboC, я буду вполне счастлив.

Боюсь, тебе придется писать его самому, не полагаясь на чудеса MPS или Racket. Почитав статью, я бы начал с рассмотрения xText, потом - C++/ANTLR/Qt.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Зато на нём реализовали рюшечки, близкие к запрашиваемым

yoghurt ★★★★★
()
Ответ на: комментарий от anonymous

> Винтажные DSL надо и реализовывать винтажными методами. Парсер и кодогенератор на Фортране, отладка в стековой VM

...обязательно с двухбуквенными мнемониками.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А документация должна пестреть киррилическими АББРВТРМИ. Стек должен называться магазином, код в ЭВМ должен грузиться с НЖМД...

anonymous
()
Ответ на: комментарий от anonymous

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

Посмотрел pfront — интересная вещь, но к сожалению только под .NET. И непонятно, живо ли оно вообще и где его достать.

А Racket интересно выглядит, буду смотреть.

ringill
() автор топика
Ответ на: комментарий от ringill

А не проще ли будет писать хотя бы на s-expr и транслировать их в СЛОН? А трансляцию написать самому.

bik ★★
()
Ответ на: комментарий от ringill

> Посмотрел pfront — интересная вещь, но к сожалению только под .NET.

Не смотри. Я когда искал средство для разработки DSL под .NET попробовал это поделие (тогда еще скачать можно было), проблевался. Аффтар тупой на всю голову, даже Драконью книгу явно не осилил.

У меня было несколько больше надежд на Nemerle - там приличный, быстрый парсер, не packrat уродский (они тот же шарп парсят быстрее чем csc), интересная система типов, довольно разумно сделанные макросы. Отпугнула только недоделанность и нестабильность языка и очень неадекватные фанбои.

Пробовал и F#, но меня быстро задолбал его бесчеловечный синтаксис.

Остановился на простом и банальном C#. Но если бы существовал Racket под .NET, перешел бы на него не задумываясь. Bigloo под .NET недоделанный и сам не managed.

anonymous
()
Ответ на: комментарий от ringill

> Зачем транслировать sexpr в СЛОН? Пользователи пишут на СЛОН-е.

Так СЛОН - это сам ДСЛ, а не хост-язык? Тогда в чем смысл сабжа?

anonymous
()
Ответ на: комментарий от anonymous

> Так СЛОН - это сам ДСЛ, а не хост-язык?

Да. Задача — сделать приемлемые инструменты для работы с этим языком.

ringill
() автор топика
Ответ на: комментарий от ringill

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

На ошибки eDSL на CL будут выглядеть, как подробное (или, наоборот, неподробное) изложение мировоззрения лисповым компилятором. В смысле, много лисповых кишков наружу вытаскивается. Но в pre-ANSI спецификации языка (Common Lisp: The Language, 2nd edition) есть степпер, на базе которого можно написать отладчик для DSL. Т.е. у вам будет некоторая функция, которой рекурсивно будут спускаться выполняемые формы, а она должна вернуть результат вычисления этой формы. В Лиспворксе этот степпер до сих пор есть, и у него есть специальная гуйня.

Однако, надо учитывать, что eDSL на лиспе выглядит, как лисп.

mv ★★★★★
()
Ответ на: комментарий от mv

> В Лиспворксе этот степпер до сих пор есть, и у него есть специальная гуйня.

Это хорошо, однако Lispworks платный. Не то чтобы это совсем недопустимо, но нежелательно. В бесплатных лиспах такого нет?

Однако, надо учитывать, что eDSL на лиспе выглядит, как лисп.

Почему, а как же всякие reader macros?

ringill
() автор топика
Ответ на: комментарий от bik

Как при чём. Слон — это DSL. Делать свои транслятор и отладчик с нуля я не хочу. Я ищу инструменты для автоматического создания оных, об этом и топик.

ringill
() автор топика
Ответ на: комментарий от ringill

В бесплатных лиспах такого нет?

Которые cltl2 поддерживают (полностью, не так выборочно, как sb-cltl2 для sbcl), там есть.

Однако, надо учитывать, что eDSL на лиспе выглядит, как лисп.

Почему, а как же всякие reader macros?

Я бы не назвал это eDSL'ем. Ну, может быть, я с ними не работал. Но неизвестно, как с не-s-expression языком степпер будет себя вести. Скорее всего, никак.

Для создания рабочего дебаггера для DSL нужна не менее мощная заточка инструмента, чем для создания самого DSL. В Common Lisp формулировка дебаггера расплывчатая, реализации вообще позволяется его не иметь. Поэтому я бы на твоём месте смотрел на другие языки, в которых можно обойтись меньшей кровью.

mv ★★★★★
()
Ответ на: комментарий от ringill

Как раз-таки транслятор с нуля вы и хотите :) А отладчик.. Вы что, правда, думаете, что лисповый (к примеру) отладчик макросов заменит специализированный отладчик для конкретного языка?

bik ★★
()
Ответ на: комментарий от ringill

Там на странице понапиханы обрывочные методы, тобишь куски классов, их просто так не запустишь :)

Вот в этом документике со 132й страницы даются примеры в более разжеванной и пошаговой форме, но в смолтоковом окружении научиться работать всё равно придется.

yoghurt ★★★★★
()

antlr. Есть что-то похожее на IDE, хоть и корявое, и мануал, хоть и у%бищный. Пользоваться можно, вобщем.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от bik

Э, нет, это ты все путаешь. ТС как раз и хочет написать новую реализацию для существующего DSL.

anonymous
()
Ответ на: комментарий от yoghurt

Вроде что-то получилось, спасибо.

ringill
() автор топика
Ответ на: комментарий от vasily_pupkin

ANTLR не даёт средств для отладки программ на DSL. Он позволяет отлаживать грамматику, но это не то.

ringill
() автор топика
Ответ на: комментарий от ringill

> Это хорошо, однако Lispworks платный. Не то чтобы это совсем недопустимо, но нежелательно. В бесплатных лиспах такого нет?

В Racket есть и макро-степпер и отладчик, который корректно обрабатывает source location произведенных макросами форм. И лиспворксу до них далеко весьма.

anonymous
()
Ответ на: комментарий от ringill

> Как при чём. Слон — это DSL. Делать свои транслятор и отладчик с нуля я не хочу. Я ищу инструменты для автоматического создания оных, об этом и топик.

А есть какие-нибдь требования к хост-языку? Ну там производительность, например?

anonymous
()
Ответ на: комментарий от bik

> отладчик макросов заменит специализированный отладчик для конкретного языка?

Отладчик макросов - не заменит, а вот обычный отладчик - вполне заменит. Но напильником, конечно, немного доработать его придется.

anonymous
()
Ответ на: комментарий от anonymous

Нет, производительность не критична.

ringill
() автор топика
Ответ на: комментарий от ringill

Омг. Тебе еще отладчик из коробки подавай. Интересно, это вообще возможно?

vasily_pupkin ★★★★★
()

Для парсинга LL - ИМХО лучший вариант ANTLR. Если хочешь компилировать (JIT тоже сюда входит) - LLVM. Если хватит самой примитивной интерпретации - просто реализуй ее сам.

С дебагом все зависит от компиляции/интерпретации. В случае интерпретации - ничто не мешает запилить свой дебаггер, в случае компиляции - у LLVM есть поддержка дебаг-информации.

Deleted
()
Ответ на: комментарий от theos

Создавать язык с расчетом на предельно простую грамматику.

Deleted
()
Ответ на: комментарий от theos

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

По-этому надо брать лисп, там все это будет искаробки.

anonymous
()
Ответ на: комментарий от anonymous

Нет, там все «вылавливается и идентифицируется» искаробки. То есть весь АД - скрыт от пользователя.

anonymous
()
Ответ на: комментарий от theos

Да, оказывается, что в MPS такой вещи, как парсер. DSL-программа задаётся и редактируется непосредственно в виде AST. Редактор украшает AST так, что оно выглядит как текст, но таковым не является. AST из исходного текста автоматически не получить.

То есть в MPS вы не можете компилировать/запускать свои DSL-программы из текстовых файлов. Вы должны создавать их в MPS с самого начала. Довольно серьёзное ограничение.

ringill
() автор топика
Ответ на: комментарий от ringill

> в MPS такой вещи, как парсер.

в MPS нет такой вещи, как парсер.

ringill
() автор топика
Ответ на: комментарий от ringill

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

theos ★★★
()
Ответ на: комментарий от yoghurt

Helvetia — хорошая разработка, но к сожалению заброшена автором (защитил PhD и ушёл в работать Google). Больше никто, насколько я понял, этот проект не развивает, не портирует на современные версии Pharo, на Squeak и т.д. В общем, вещь отличная и в чём-то уникальная, но связываться с ней в долгосрочной перспективе — рискованно.

ringill
() автор топика
Ответ на: комментарий от ringill

Не всё так мрачно :)

В общем, вещь отличная и в чём-то уникальная, но связываться с ней в долгосрочной перспективе — рискованно.

А я, если честно, так и не понял, в чём поинт? Вы хотите некое средство для создания DSLей, чтобы юзать их в каком-нибудь продакшне потом, или из чисто теоретического интереса?

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

> Не всё так мрачно :)

Ну... автор перенёс Helvetia с Pharo 1.1.1 на Pharo 1.1.2. Тогда как сейчас в ходу Pharo 1.3. И в проекте он единственный участник. В общем, если сравнивать с Racket, которая часто обновляется и имеет достаточно сильное комьюнити, то Racket кажется перспективнее.

Вы хотите некое средство для создания DSLей, чтобы юзать их в каком-нибудь продакшне потом

Так точно, в продакшене, возможно уже в следующем году.

ringill
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.