Для каких проблем вы пишете DSL? - PullRequest
18 голосов
/ 10 июля 2009

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

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

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

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

Редактировать: Извините, что ставлю это после, но я имел в виду конкретный DSL, который вы написали сами. Это исключает Tex, HTML, Make, SQL. На самом деле вопрос был больше: «написание DSL»

Ответы [ 12 ]

8 голосов
/ 10 июля 2009

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

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

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

8 голосов
/ 10 июля 2009

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

  • UIL - Здание с графическим интерфейсом
  • Make - сборка и установка программы
  • регулярное выражение - Соответствие строковому шаблону
  • lex и yacc - создание лексического анализатора и компилятора

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

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

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

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

7 голосов
/ 10 июля 2009

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

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

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

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

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

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

datadef Object1Datadef
{

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

}

root MyObject
{
    datadef Object1Datadef;

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

    int _Myvariable;    

}

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

6 голосов
/ 10 июля 2009

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

3 голосов
/ 05 октября 2009

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

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

3 голосов
/ 10 июля 2009

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

  1. Использование библиотеки construct - которая в основном определяет DSL для описания двоичных структур данных (таких как форматы файлов) и протоколов.
  2. Реализация DSL на основе Python для проверки оборудования. Этот DSL представляет всю инфраструктуру, необходимую для написания тестов, в качестве «функций сценария», которые могут использовать базовые компоненты DSL.
2 голосов
/ 25 июня 2010

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

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

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

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

2 голосов
/ 05 октября 2009

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

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

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

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

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

2 голосов
/ 10 июля 2009

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

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

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

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

0 голосов
/ 11 июля 2009

Я все еще студент, но я действительно очарован духом

Я немного использовал его в курсе «Языки программирования». Вот как это работает, в основном вы пишете EBNF.

альтернативный текст http://img6.imageshack.us/img6/1461/reala.png

становится этим в C ++ ;)

альтернативный текст http://img6.imageshack.us/img6/8809/dsl.png

...