For what kind of problems do you write a DSL?

Question

I'm just curious about Domain-Specific Languages. I have seen them several times in articles, and it seems that they can be used outside assurance or bank data definition problems.

So I come to SO to have some concrete input.

Did you ever use a DSL? Write one. If yes, what's it feel like?

Do you think one of your projects could be better (more productive, more maintainable, ...) with a DSL?

Edit : I'm sorry to put this after, but i was meanning a specific DSL that you wrote yourself. It's exclude Tex, HTML, Make , SQL. I fact, the question was more : "writing a DSL"

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

How about BNF as a DSL for parser generators?

Answer 5

DSLs created with the Visual Studio DSL Toolkit can be used to generate any text-based artifact from an instance of the domain model defined by the DSL. Of course, being inside of Visual Studio at the time, if there's a compiler or other processor for the text artifact, then it can automatically be run.

Some examples are

• NORMA, a DSL for conceptual domain modeling, based on Object-Role Modeling notation (ORM2)
• Web Service Software Factory, which uses three DSLs to model web services
• Configuration Section Designer - used to define the schema for XML configuration files and to generate the classes to expose the data from them.

And, of course, you can create your own.

Answer 6

I'd say there is quite a continuum between very readable API as a weak form of DSL (what some call a fluent interface), an internal DSL as something in between and a full grammar-defined external DSL on the other end.

The weakest form is something that I kind of always try to achieve (i.e. make the API as closest to the problem domain as possible). A DSL on the other end of the continuum makes a lot of sense if non-programmers will be using the software, e.g. to enter data.

And with a framework like Xtext even a full external DSL, including an editor supporting syntax coloring and error checking is much easier to implement than it might initially seem.

Answer 7

Actually, you use DSLs almost everyday without knowing it... HTML, make, XML, latex and many many configuration languages...

I enjoy having a declarative DSL that generates a bunch of things...It feels good...

What is the impact of a DSL is an interesting but really difficult to assess... If your DSL is well designed for the targeted community (the targeted community is a really important point...) in terms of what this community is expecting and does well the job it is supposed to do, it's going to feel good...

However, if you design a DSL without knowing the community or if they need to constantly fight with the limitations of the language (a DSL can still be turing-complete...), it's going to hurt...

Answer 8

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.

Answer 9

In my experience, any software-engineering organization will create DSLs in response to repeated problems and too much template code being written. A short extract from my personal experience:

• Compiler bottom-up rewrite-system generators
• Assembler generators
• Object-code generators (implemented as a C++ library with operator overloading)
• CPU simulator generator
• Simulator device model generator
• Command-line languages for interactive tools

Also note that many file formats can be considered DSLs if you look closely.

There was a good article by Mark Shapiro in ACM Queue a while back about this phenomenon too.

Yet another example is the way in which users end up writing big programs in things not intended for it... like test benches using the old "SNIFF" debugger scripting language.

Answer 10

I was one of the people that worked on NUnit version 2.0 and up for a few years. It is a DSL written using C# attributes to describe unit tests. It isn't the most obvious example of a DSL, but I have come to think of it as one. I have written some other ones using ANTLR and even MGrammar. The experience is often the same. As soon as you show it to someone else they want to do a bunch of things you never thought of. That's a good thing, but you have to be prepared to keep going and add functionality.

I'm now in the habit of thinking about and writing DSLs quite often. The current object relational mapper I use is a dsl. It isn't a new language. It is pure C#, but by thinking of the language of the Domain, and that Domain is more than just Business Domain, we created a mini language to map objects. Thinking in terms of DSLs has changed our approach to API and framework building.

Answer 11

This might be an old question, but the question in the title (rather than in the body) has not really been answered by anyone:

There are two (dual) instances in which it makes sense to write a DSL:

• When the problem-domain is very well understood and has pre-existing vocabulary of nouns (objects), verbs (actions, combinators, etc) and adjectives (attributes, modifiers).
• When the solution-domain is very well understood and ...

Regular expressions are a good example of the first, while assembler-generators the second. General purpose programming language are there for the rest: when neither the problem-domain nor the solution-domain is that well understood, and so general tools have to be brought to bear.