Dsl Boundary

When the topic of DomainSpecificLanguage comes up, one of the common puzzles is exactly what is or isn't a DSL. The trouble is that there is no precise definition for a DSL and there is a large gray area between DSLs and other things.

For me, a key element is that DSLs are limited both in scope (they refer to a particular domain) and capability (they lack features that are basic for general purpose languages). As a result good DSLs are usually small and simple: hence terms like 'little languages' and 'mini-languages'.

For internal DSLs, the fuzzy boundary is what is an API and what is a DSL. Fundamentally there is no difference, an internal DSL is just an API with a fancy name (as the old Bell labs saying goes: “library design is language design”). Despite this, however, I think there is a different feel when you are working with an API that's written with a DSL feel. Things like a FluentInterface can make working with an API a qualitatively different experience. Thinking in DSL terms makes you think about readability in a different way, exploiting the syntax of the host language to create something that seems to stand on its own - rake is a great example of this.

When it comes to external DSLs the question often comes in the form of what the difference is between a DSL and a general purpose language (GPL). Often a clear sign is when the DSL isn't Turing complete or lacks abstraction facilities. Regexps are a fine example of this limitation in capability. SQL is a more interesting candidate. It's a complex and capable language, yet lacks both Turing completeness and the ability to build new abstractions.

Can a language be Turing complete and still be a DSL? Ploticus's script language is Turing complete, but it's clear focus on producing graphs within Ploticus makes it a DSL - at least for me. But then what about XSLT? It too has a limited focus on transforming XML documents, yet it has gained so many capabilities that increasingly people think of it as a GPL.

The example of Ploticus raises the question of whether embedded languages are DSLs. Is Excel's macro language a DSL when it's virtually the same as Visual Basic? What happens if you embed a general scripting language into an application?

As with the internal DSL vs API issue, I think the intention is the key here, both of the language writer and of the user. If I use XSLT only to transform an XML document then I'm treating it as a DSL - even if I do some fancy call out to embed some value in the output document. However if I use it to solve the eight queens puzzle I'm using it as a GPL. If the designers of XSLT see it as about XML transformations then they are thinking of it as a DSL even if clever people do unnatural acts with it.

This is one of those discussions are interesting ones to have in the pub but shouldn't detract from the good ideas in using DSLs. DSLs should be designed as used to be a limited language tightly focused on a single problem. If you go into their design and use with that idea foremost, they'll be useful. And after all it's usefulness that really counts.