The structure of Domain-Specific Languages
In previous posts I’ve talked a bit about DSLs, DSL in the context of MDE and DSL compared to UML and MDA. While the term DSL is often used nowadays, its interesting to look at the different structures a DSL can have. DSLs can be implemented using various structures, like textual languages, graphical languages, wizards and interactive GUIs, or a combination of the previous. In principle the structure of a DSL can vary along two different axes: the range of variation and the notation.
The appropriate structure of a DSL depends on the range of variation that needs to be supported. This axis ranges from routine configuration to creative construction and contains the following possible values (Czarnecki, 2004):
- Routine configuration using wizards, representing a path through a decision tree. It can be discussed whether wizards are languages or not.
- Feature-base configuration, i.e. constructing a sub tree of a feature model for a certain domain.
- Creative construction using graph-like languages.
The choice for a specific structure depends on the problem domain and the target users. Expert users, for example, may prefer freedom, while infrequent users and novices are better suited with wizard like languages.
On the notation axis a difference can be made between Domain-Specific Visual Languages (DSVL) and textual DSLs. The choice for a DSL or a DSVL mostly is a point of discussion. For a large number of specialist application- or problem-domains there exist a natural and intuitive visual representation of artifacts in these domains. These visual representations are often what practitioners in these fields have been using all along, which reduces training costs and lowers the barriers to acceptance. In principle we can say that the language should offer graphical constructs in the cases that the concepts represented are more concise and intuitive in graphical form compared to a textual one. However, much developers and specialists prefer textual languages, which they say to be more productive and have better tool support. Although DSVLs are easier and faster to read, I think the choice for a notation depends on the target user.
While the choice for a DSL structure can be a tough one, a more flexible approach is to use an intermediate program representation to allow using different DSL renderings with different generator back-ends. Figure 1 visualizes the use of an intermediate DSL. DSL renderings can by example be textual or visual. Examples of generator back-ends are Stratego/XT, oAW xText, and ANTLR. xText uses ANTLR for parsing but has some significant differences.
Figure 1 – Using an intermediate DSL
An intermediate DSL can also be useful for combining multiple DSLs (e.g. for different system aspects or subject area’s), by first rewriting them into an intermediate DSL before actually generating executable code.
Krzysztof Czarnecki. Overview of generative software development. In UPP, pages 326-341, 2004.