The Structure of Domain Specific Languages

In the beginning was the configuration file and we saw that it was good . . .

Even in a scripting language where there is no compile step to worry about, a config file is great as it allows you to pull certain settings out of your code base and to give yourself or your customers easy ways to make certain changes without having to mess with the code.

But simple, flat configuration files are limited. A lot of the data we deal with is hierarchical in nature and with a hierarchical data structure that supports elements with 0..n child nodes recursively (and ideally also with support for composability) you can model a LOT of problem domains. And thus our love affair with XML (as one of the most common concrete syntaxes for describing hierarchical data) was born.

For every problem domain I have come across so far, it has been possible to create a representation of the grammar of each DSL required using Relax NG. Other possible syntaxes would have been XML Schemas, DTDs or Extended BNF. This means that every DSL (that I’ve been able to think of to date) could conceptually be written using XML if required.

Multiple Projections Of course, you often want to write your DSL using anything from freeform text to drawing a diagram or using a state table or a web based wizard, but those are simply projections of the underlying data. Formally they are called concrete syntaxes and transforming between concrete syntaxes that share the same abstract syntax is a fairly trivial automatable process.

So, this starts to give us a meta-model of the structure of Domain Specific Languages and the concept that a diagram, a state table, an XML file and a simple text file are just different projections of the underlying DSL that we could allow developers to swap between easily and automatically.

The core structure of these Domain Specific Languages? 0..n elements, each of which can be comprised of 0..n elements. Each element can have cardinality of 0..1, 0..n, 1..1 or 1..n. All leaf elements must be of a data type (and enumerations and lists are supported).

OK, I am hoping that this is as theoretical as I’m going to have to get for a while. Tomorrow I’ll be working on describing a number of projects I want to generate and will be refining my DSL’s to see how well they describe the problem spaces.