Поскольку, какие проблемы Вы пишете DSL?

Предел виртуального адресного пространства для процесса Win32 составляет 1,5 ГБ (не совсем верно). Кроме того, в платформах .NET существует ограничение на процент памяти, который может потреблять процесс .NET. В файле machine.config есть элемент processModel с атрибутом memoryLimit, который представляет собой% доступной памяти, которую процесс может использовать. Значение по умолчанию - 60%.

Если компьютер, на котором вы работаете, имеет 2 ГБ памяти или вы не включили переключатель / 3GB в вашем BOOT.INI, то вы получите ~ 1,3 ГБ памяти на каждый

Я не могу найти статью в базе знаний, но, если я правильно помню, .NET 1.x не может обращаться за пределами лимита 1,5 ГБ (1,8 ГБ?) независимо от ваших настроек.

http: //blogs.msdn .com / tmarq / archive / 2007/06/25 / some-history-on-the-asp-net-cache-memory-limits.aspx http://social.msdn.microsoft. ru / Forums / en-US / clr / thread / c50ea343-b41b-467d-a457-c5a735e4dfff http://www.guidanceshare.com/wiki/ASP.NET_1.1_Performance_Guidelines_-_Caching#Configure_the_Memory_Limit

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

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

А с такой структурой, как Xtext , даже полный внешний DSL,

I think the DSL most of us use most often is SQL, a little language for data manipulation and extraction.

SQL's a good example Michael Dorfman gave. Others I have used extensively are:

• UIL - GUI building
• Make - program building and installing
• regexp - String pattern matching
• lex and yacc - lexical analyzer and compiler creation

As for how it works out, I think it depends on the language and the domain. UIL is out-and-out awesome for specifying GUI's. If you do the same thing in inline Motif code, GUI specification errors that the UIL compiler catches look like perfectly compilable code to a C or Ada compiler. That causes tons more time to be wasted debugging. Plus, it just plain looks uglier in general-purpose code using Motif API calls.

Make can really get to be a nightmare, but there aren't a lot of tools out there that can do what it does, and I suspect they all have the same problem.

Regular expressions are unneeded for very simple tasks, and a nightmare for really complex ones. For those in the middle, they are a wonderful tool.

Lex and yacc can be quite helpful. However, a person who knows what they are doing can create parsers and lexical analyzers by hand with about the same amount of work.

Two recent uses of a DSL:

1. Using the construct library - which basically defines a DSL for describing binary structures of data (such as file formats) and protocols.
2. Implementing a Python-based DSL for verifying hardware. This DSL lays out all the infrastructure required to write tests as "scenario functions" that can use the underlying DSL components.

Your question is quite well timed. I have recently written a DSL using the tool Antlr. Antlr is a parser/lexer generator.
It allows easy construction of DSLs (and many other things) and when coupled with StringTemplate (written by the same person) becomes very powerful in code generation. It also can target multiple languages. Our parser and lexer is in C# (one of the targets) even though the default is Java.

One of the numerous benefits of Antlr are the descriptive error messages and the IDE/debugger (AntlrWorks) which allows you to step through your grammar and see the AST trees visually.

John Saunders suggested below the use of the built in visual studio DSL toolkit. Ultimately, I found those tools to be far to constricting. To require a GUI, without any ability to easily describe an underlying textual grammar, just seems inadequate for my needs.

Along with the DSL parser/lexer I have also written a Visual Studio Language service, to provide intellisense, error highlighting, code completion and template items/projects.

Even if you dont implement the extras, a DSL can simplify repetitive work. My DSL specifically targets the CSLA framework, generating business objects easily with all the plumbing, allowing the developers to only worry about business logic.

Here is a small example of the DSL:

datadef Object1Datadef
{

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

}

root MyObject
{
    datadef Object1Datadef;

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

    int _Myvariable;    

}

If your DSL allows you to describe your domain faster, more easily and increases productivity, then it is worthwhile.

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

Мне нравится декларативный DSL, который генерирует множество вещей ... Приятно ...

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

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

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

Некоторыми примерами являются

• NORMA , DSL для концептуальной области моделирование

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

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

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

alt text http://img6.imageshack.us/img6/1461/reala.png

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

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

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

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

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

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

• Компилятор восходящие генераторы системы перезаписи
• Генераторы ассемблера
• Генераторы объектного кода (реализованные как библиотека C ++ с перегрузкой оператора)
• Генератор имитатора ЦП
• Генератор модели устройства имитатора
• Команда -строчные языки для интерактивных инструментов

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

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

• Компилятор восходящие генераторы системы перезаписи
• Генераторы ассемблера
• Генераторы объектного кода (реализованные как библиотека C ++ с перегрузкой оператора)
• Генератор имитатора ЦП
• Генератор модели устройства имитатора
• Команда -строчные языки для интерактивных инструментов

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

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

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

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

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

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