Создание DSL: написано на языке общего назначения или автономно?

10

Я обсуждаю разработку предметно-ориентированного языка, чтобы упростить данную неясную модель программирования. Частью дискуссии является вопрос о том, следует ли создавать его (в виде скрипта) поверх существующего языка / среды выполнения (например, Java) или сделать его автономным (собственный компилятор и т. Д.).

Те из вас, у кого есть опыт проектирования DSL, у вас есть плюсы / минусы или верный ответ на соответствующий подход?

— Jé Queue
источник

кто является потребителем этого DSL? и каковы потенциальные хосты (вы упомянули Java, рассматриваете ли вы другие возможности)?

— Маурисио Шеффер

Я рассматриваю любую возможность для хозяев. Потребителями будут те, кто пишет асинхронные программы (сообщения с адресатами).

— Jé Queue

9

Я бы порекомендовал создать свой DSL поверх существующего языка (внутреннего DSL). Я делал это несколько раз с Python, создавая системы, в которых потребитель DSL записывает файл python, который используется в качестве файла конфигурации системы. Файл конфигурации использует определенные мной конструкции (классы, функции). Эти конструкции образуют DSL.

IMO, такой язык, как Python (IronPython или Jython, если хост-система - .NET или Java) или Ruby (IronRuby, JRuby), лучше использовать в качестве основы DSL, чем Java или C #.

В моем случае хост-системы также были (C) Python, поэтому выбор Python для DSL был естественным.

Некоторые плюсы:

Более низкая стоимость строительства. Существует намного меньше для вас, чтобы реализовать. Вы можете сосредоточиться на проблеме, а не тратить время на реализацию парсера / компилятора / интерпретатора.
Доступ к языку хоста: Ваш язык будет иметь доступ ко всем возможностям существующего языка / платформы.

— codeape
источник

Я довольно независим от языка, но почему вы думаете, что воплощения Python лучше подходят?

— Jé Queue

1

Лучше подходит чем чем? Я предполагаю, что Ruby и Python имеют много одинаковых преимуществ, возможно, Ruby даже лучше подходит для внутреннего DSL из-за его более гибкого синтаксиса. Что касается Java и C #, я видел много отличного интерфейса на этих языках (и в более новых версиях есть конструкции, которые облегчают создание / использование внутреннего DSL, такие как синтаксис инициализатора объекта) - но IMO языки "низкой церемонии" немного лучше, чем языки "высокой церемонии".

— Кодеап

1

Я выбрал C # для точной реализации внутреннего DSL, чтобы использовать «бесплатную» статическую проверку типов во время компиляции. Динамические языковые DSL не дают слишком много преимуществ по сравнению с внешними DSL.

— Ден

@ Это именно то, что разочаровало меня, когда я попытался сделать iDSL в Python. В Java ваш iDSL чувствует, что он получает мгновенную поддержку от IDE. Не нашли IDE, которая сделает это для Python.

— candied_orange

2

Посмотрите на Xtext (http://www.eclipse.org/Xtext/) и Xbase (http://blog.efftinge.de/2010/09/xbase-new-programming-language.html). Если пользователи не программисты, я не думаю, что вы должны основывать свой DSL на существующем языке программирования. Это будет слишком сложно для них. «Чистый» DSL может быть очень эффективным, если сделан правильно.

— Хенрик
источник

2

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

— eggsyntax
источник

1

Есть третий вариант - создать DSL как компилятор поверх языка общего назначения. Любой язык с некоторой разумной степенью возможностей метапрограммирования сделает свою работу, включая даже такую низкоуровневую вещь, как C ++. Я предпочитаю Lisp и подобные языки для такого рода вещей, но Template Haskell или Nemerle также могут обеспечить такой же уровень гибкости.

— SK-логика
источник

1

В своей книге «Специфичные для домена языки» Мартин Фолвер описывает внутренние и внешние DSL.
Internal DSL= является подмножеством существующего языка программирования, например, Ruby / Java и т. д.
External DSL= вы определяете синтаксис и словарь.
Внешний DSL может быть гораздо более выразительным, но может потребовать внешнего анализа и генерации кода.
Хотя внутренний DSL не требует дополнительной обработки, его иногда трудно понять специалистам, не занимающимся программированием (например, бизнес-аналитикам, тестировщикам).

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

— Ольга Павлюк
источник