Подтвердить что ты не робот

Для каких проблем вы пишете DSL?

Мне просто интересно узнать о доменах. Я видел их несколько раз в статьях, и кажется, что они могут использоваться вне проблем обеспечения или банковских данных.

Итак, я пришел к SO, чтобы получить конкретный вклад.

Вы когда-нибудь использовали DSL? Напишите один. Если да, каково это?

Считаете ли вы, что один из ваших проектов может быть лучше (более продуктивным, более ремонтопригодным,...) с DSL?

Редактировать: Мне жаль, что я поместил это после, но я имел в виду конкретную DSL, которую вы написали сами. Это исключает Tex, HTML, Make, SQL. Я факт, вопрос был больше: "писать DSL"

4b9b3361

ОТВЕТЫ

Ответ 1

Я был одним из людей, которые работали над NUnit версии 2.0 и в течение нескольких лет. Это DSL, написанная с использованием атрибутов С# для описания модульных тестов. Это не самый очевидный пример DSL, но я подумал об этом как о одном. Я написал несколько других, используя ANTLR и даже MGrammar. Опыт часто один и тот же. Как только вы показываете это кому-то другому, они хотят сделать кучу вещей, о которых вы никогда не думали. Это хорошо, но вы должны быть готовы продолжать и добавлять функциональность.

Я уже привык думать и писать DSL довольно часто. Текущий реляционный сопоставитель объектов, который я использую, - это dsl. Это не новый язык. Это чистый С#, но, думая о языке домена, и этот домен больше, чем просто Business Domain, мы создали мини-язык для сопоставления объектов. Мышление в терминах DSL изменило наш подход к API и построению каркаса.

Ответ 2

SQL хороший пример Майкл Дорфман дал. Другие, которые я использовал широко:

  • UIL - здание GUI
  • Make - создание и установка программ
  • regexp - соответствие шаблону строки
  • lex и yacc - создание лексического анализатора и компилятора

Что касается того, как это работает, я думаю, что это зависит от языка и домена. UIL отлично подходит для указания GUI. Если вы делаете то же самое в встроенном коде Motif, ошибки спецификации GUI, которые улавливаются компилятором UIL, выглядят идеально компилируемым кодом для компилятора C или Ada. Это заставляет потратить больше времени на отпугивание. Кроме того, он просто выглядит уродливым в коде общего назначения, используя вызовы API Motif.

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

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

Lex и yacc могут быть весьма полезными. Тем не менее, человек, который знает, что они делают, может создавать парсеры и лексические анализаторы вручную с примерно одинаковым объемом работы.

Ответ 3

Я бы сказал, что между очень читаемым API существует довольно широкий спектр как слабый вид DSL (то, что некоторые называют свободным интерфейсом), внутренняя DSL как нечто среднее между собой и полная грамматическая внешняя DSL на другом конце,

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

И с фреймворком вроде Xtext даже полный внешний DSL, включая редактор, поддерживающий синтаксическую раскраску и проверку ошибок, намного проще реализовать чем это может показаться на первый взгляд.

Ответ 4

Ваш вопрос довольно приурочен. Недавно я написал DSL с помощью инструмента Antlr. Antlr - генератор парсера/лексера.
Это позволяет легко создавать DSL (и многое другое) и в сочетании с StringTemplate (написанное одним и тем же человеком) становится очень мощным в коде поколение. Он также может ориентироваться на несколько языков. Наш парсер и лексер находятся в С# (одна из целей), хотя по умолчанию используется Java.

Одним из многочисленных преимуществ Antlr являются описательные сообщения об ошибках и IDE/debugger (AntlrWorks), которые позволяют вам пройти через вашу грамматику и визуально увидеть деревья AST.

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

Наряду с парсером DSL/lexer я также написал службу языка Visual Studio, чтобы обеспечить intellisense, подсветку ошибок, завершение кода и элементы/проекты шаблонов.

Даже если вы не реализуете дополнительные функции, DSL может упростить повторяющуюся работу. Мой DSL специально нацелен на структуру CSLA, легко создавая бизнес-объекты со всей сантехникой, позволяя разработчикам беспокоиться только о бизнес-логике.

Вот небольшой пример DSL:

datadef Object1Datadef
{

   tables
   {
      MyTable:PK[MyTableID], column1, column2;
   }

}

root MyObject
{
    datadef Object1Datadef;

    read "all";
    write "admin", "superusers";

    int _Myvariable;    

}

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

Ответ 5

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

Ответ 6

Два недавних использования DSL:

  • Используя библиотеку construct, которая в основном определяет DSL для описания двоичных структур данных (таких как форматы файлов) и протоколов.
  • Реализация DSL на основе Python для проверки аппаратного обеспечения. Этот DSL предоставляет всю инфраструктуру, необходимую для написания тестов как "функции сценария", которые могут использовать базовые компоненты DSL.

Ответ 7

На самом деле, вы используете DSL почти каждый день, не зная об этом... HTML, make, XML, латекс и многие языки программирования...

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

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

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

Ответ 8

По моему опыту, любая инженерно-техническая организация создаст DSL в ответ на повторяющиеся проблемы и слишком много написания кода шаблона. Краткий отрывок из моего личного опыта:

  • Генераторы переписывающих систем восходящего потока компилятора
  • Генераторы ассемблера
  • Генераторы объектных кодов (реализованы как библиотека С++ с перегрузкой оператора)
  • Генератор симулятора процессора
  • Генератор модели устройства моделирования
  • Языки командной строки для интерактивных инструментов

Также обратите внимание, что многие форматы файлов можно рассматривать как DSL, если вы внимательно присмотритесь.

Была хорошая статья Марк Шапиро в очереди ACM снова об этом явлении.

Еще один пример - это способ, которым пользователи в конечном итоге пишут большие программы в вещах, не предназначенных для него... например, скамьи для тестирования, используя старый сценарий сценариев отладки SNIFF.

Ответ 9

Это может быть старый вопрос, но вопрос в заголовке (а не в теле) на самом деле не ответил никому:

Есть два (двойных) экземпляра, в которых имеет смысл написать DSL:

  • Когда проблемная область очень хорошо понята и имеет уже существующий словарь существительных (объектов), глаголов (действий, комбинаторов и т.д.) и прилагательных (атрибутов, модификаторов).
  • Когда область решения хорошо понятна и...

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

Ответ 10

Как насчет BNF как DSL для генераторов парсеров?

Ответ 11

DSL, созданные с помощью Visual Studio DSL Toolkit, могут использоваться для создания любого текстового артефакта из экземпляра модели домена, определенной DSL. Конечно, находясь внутри Visual Studio в то время, если есть компилятор или другой процессор для артефакта текста, он может автоматически запускаться.

Некоторые примеры

  • NORMA, DSL для концептуального моделирования домена на основе нотации моделирования объектной роли (ORM2)
  • Программное обеспечение веб-сервисов Factory, которое использует три DSL для моделирования веб-сервисов.
  • Design Section Designer - используется для определения схемы для файлов конфигурации XML и для генерации классов для отображения данных из них.

И, конечно же, вы можете создать свой собственный.