A domain-specific language (DSL) can be viewed as a programming language dedicated to a particular domain or problem. It provides appropriate built-in abstractions and notations; it is usually small, more declarative than imperative, and less expressive than a general-purpose language (GPL).

For example, Unix shells can be considered as DSLs whose domain abstractions and notations include streams (such as stdin and stdout) and operations on streams (such as redirection and pipe). Shells also offer a simple interface to running and controlling processes. They contain simple control-flow and string manipulation mechanisms, that cover a lot of common usages. Even though they are Turing-complete, they differ from GPLs in that they are unsuitable to manipulate, e.g., complex data structures, which restrict in practice their use to the “gluing” facility provided by scripting languages.

DSLs have also been called micro-languages, application languages, and very high level languages.

Because DSLs can be highly declarative and hide much of the implementation details, some of them can be considered more as specification languages than programming languages. Those specifications are often executable, though. The key characteristics are still specific abstractions and notations as well a restricted (or rather focused) expressive power.

Consider for example the Unix command make. This tool is a utility to maintain programs: it determines automatically which pieces of a large program need to be recompiled, and issues the commands to recompile them. The language of makefiles is small (at least in the early versions of make) and mainly declarative, although it also contains some imperative constructs. Its expressive power is limited to updating task dependencies; actual recompilation actions are delegated to a shell. It hides implementation details like file last-modification time and provides domain abstractions such as file suffixes and implicit compilation rules. As a result, the user may concisely and precisely express update dependencies. Why to use a DSL? DSLs are more attractive than GPLs for a variety of applications, as illustrated by the above shell and makefile language examples.

Because of appropriate abstractions, notations and declarative formulations, a DSL program is more concise and readable than its GPL counterpart. Hence, development time is shortened and maintenance is improved. As programming focuses on what to compute as opposed to how to compute, the user does not have to be a skilled programmer. For example, in the case of recompilation, writing a program to explicitly test all file modification times in order to incrementally rebuild a system would clearly be lengthy, tedious and error-prone, as opposed to using a makefile.

Most GPL programming environments include the ability to group common operations into libraries. Though some are standard libraries, re-use is left to the programmer. On the other hand, a DSL offers guidelines and built-in functionalities which enforce re-use. Additionally, a DSL captures domain expertise, either implicitly by hiding common program patterns in the DSL implementation, or explicitly by exposing appropriate parameterization to the DSL programmer. Thus, any user necessarily re-uses library components and domain expertise.

Another important advantage of DSLs is that they enable more properties about programs to be checked. In contrast to a GPL, the semantics of a DSL can be restricted to make decidable some properties that are critical to a domain. For example, make reports any cycle in dependencies and thus totally prevents non-termination (assuming the individual actions do not loop).

Although all DSL features listed above address important software engineering concerns, they do not say much about the way applications based on DSLs should be structured. In fact, DSLs strongly suggest particular software architectures.

Software architectures express how systems should be built from various components and how those components should interact. From a software architecture perspective, a DSL can be seen as a parameterization mechanism as well as an interface model.

A program or a library can be more or less generic depending on the scope of the problems it addresses [Boo87]. For example, a scientific library can be highly generic considering the vast variety of problems it can be used for. Pushing the idea of genericity further leads to complex parameters that can be seen as DSLs. For example, the format string argument of function printf can be seen as both a complex parameter and a very simple DSL. Considering a DSL program as a complex argument to a highly parameterized component may sound contrived but it actually is the final step of a chain of increasingly expressive power in parameterization. This situation is illustrated by Unix commands grep, sort, find, sed, make, awk, etc., and the progression from simple command-line parameters to program files. At the end of the spectrum, the data parameter ends up being a program to be processed, yielding increased parameterization power.

As a library becomes larger or more generic, its usability decreases due to the multiplication of entry points, parameters and options offered. As a result, the library might be ignored by programmers because it is too complex to use. In this situation, a DSL can offer a domain-specific interface to the library so that the programmer does not have to directly manipulate numerous highly-parameterized building blocks; the complexity is hidden. Another common situation is when some patterns of library calls occur frequently. In this case, a DSL interface can provide direct access to those commonly used combinations. For example, Unix shells are interfaces to standard Unix libraries. Similarly, SQL hides low level queries to a database. This idea is shared by scripting languages, that glue together a set of powerful components written in traditional programming languages. For example, Tcl/Tk provides a Tcl interface on top of the Tk graphic toolkit.

Recognizing a DSL as both a parameterization mechanism and an interface has an impact on structuring and reasoning about the software. In fact, the range of software adaptability is defined by the DSL. Such software is thus naturally separable into two parts: the decoding of the parameterization expressed by DSL programs and a library of components.

One may wonder when complex parameters and library interfaces are used. Complex parameters are introduced when, instead of offering separate but related tools, a single, versatile program is provided. Libraries are in essence created to enable re-use of data types and basic operations among related programs. Thus, the common motivation of those architectures is to build a set of related programs. This observation leads to another, more conceptual aspect of DSLs: a program family.

A DSL program designates a member of a program family. A program family is a set of programs that share enough characteristics that it is worthwhile to study them as a whole [Par76]. A program family can also be seen as providing a solution to a problem family, i.e., a set of related problems. Drivers, for a given type of device, form a natural example of a program family: in addition to having the same API (for a given operating system), they all share similar operations, although they vary according to the hardware.

Conversely we believe that whenever a problem family must be solved, i.e., whenever a program family must be developed, basing the software architecture on a DSL makes configuration (i.e., DSL programming) simpler. More generally, the following issues should be raised even when developing new software:

Does the program to be developed address an isolated problem? 
Could it be a member of a future program family?

The fact is that existing DSLs do implement program families. Examples are numerous; DSLs have been used in various domains such as graphics [Ell97,KH97], financial products [ADR95], telephone switching systems [GJK+97,LR94], protocols [CL97,TCM98], operating systems [PBC+97], device drivers [TMC97], routers in networks [TCM98] and robot languages [Bja96]. This profusion, as well as the number of DSL-related events and projects, shows the recent attention that DSLs have received from both the research and industrial communities. In particular, non-trivial DSLs are developed and being exploited in large companies such as ATT, Lucent Technologies, Philips, and Motorola.

The applications listed above have clearly illustrated the advantages of DSLs over GPLs, recording benefits such as productivity (development time speedups up to 10 have been cited), reliability and flexibility [KKB+96]. However, they also raise a key issue which, if not addressed, could obstruct the use of DSLs [Cle88]: how does one design and implement a DSL? Resolving this issue is critical to make the approach profitable since there is no point in reducing the complexity of program development by shifting all the complexity into the construction and maintenance of a DSL programming environment.

Another related question is: who will develop DSLs? Even in the programming language community, only a few people have actually designed a language. A fortiori, we cannot expect software engineers to have the full expertise to build up new languages. Thus, it is crucial that a methodology and tools are provided to make the DSL approach widely accessible. Sprint [TC97,CM98] provides such a framework.

[ADR95] B.R.T. Arnold, A. van Deursen, and M. Res. An algebraic specification of a language describing financial products. In IEEE Workshop on Formal Methods Application in Software Engineering, pages 6-13, April 1995.

[Bja96] E. Bjarnason. Applab: a laboratory for application languages. In L. Bendix, K. Nørmark, and K Østerby, editors, Nordic Workshop on Programming Environment Research, Aalborg. Technical Report R-96-2019, Aalborg University, May 1996.

[Boo87] Grady Booch. Software Components with Ada. Benjamin Cummings, 1987.

[CL97] Satish Chandra and James Larus. Experience with a language for writing coherence protocols. In Proceedings of the 1st USENIX Conference on Domain-Specific Languages, Santa Barbara, California, October 1997.

[Cle88] J. Graig Cleaveland. Building application generators. IEEE Software, July 1988.

[CM98] C. Consel and R. Marlet. Architecturing software using a methodology for language development. In Proceedings of the 10th International Symposium on Programming Languages, Implementations, Logics and Programs PLILP/ALP ‘98, Pisa, September 1998. Invited paper.

[Ell97] Conal Elliott. Modeling interactive 3D and multimedia animation with an embedded language. In Proceedings of the 1st USENIX Conference on Domain-Specific Languages, Santa Barbara, California, October 1997.

[GJK+97] N.K. Gupta, L. J. Jagadeesan, E. E. Koutsofios, and D. M. Weiss. Auditdraw: Generating audits the fast way. In Proceedings of the Third IEEE Symposium on Requirements Engineering, pages 188-197, January 1997.

[Jon80] N. D. Jones, editor. Semantics-Directed Compiler Generation, volume 94 of Lecture Notes in Computer Science. Springer-Verlag, 1980. [KH97] Samuel Kamin and David Hyatt. A special-purpose language for picture-drawing. In Proceedings of the 1st USENIX Conference on Domain-Specific Languages, Santa Barbara, California, October 1997.

[KKB+96] R. Kieburtz, L. McKinney, J. Bell, J. Hook, A. Kotov, J. Lewis, D. Oliva, T. Sheard, I. Smith, and L. Walton. A software engineering experiment in software component generation. In Proceedings of the 18th IEEE International Conference on Software Engineering ICSE-18, pages 542-553, 1996.

[LR94] David Ladd and Christopher Ramming. Two application languages in software production. In USENIX Symposium on Very High Level Languages, New Mexico, October 1994.

[Par76] D.L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, 2:1-9, March 1976.

[PBC+97] C. Pu, A. Black, C. Cowan, J. Walpole, and C. Consel. Microlanguages for operating system specialization. In 1st ACM-SIGPLAN Workshop on Domain-Specific Languages, Paris, France, January 1997. Computer Science Technical Report, University of Illinois at Urbana-Champaign.

[Sch86] D. A. Schmidt. Denotational Semantics: a Methodology for Language Development. Allyn and Bacon, Inc., 1986.

[TC97] S. Thibault and C. Consel. A framework of application generator design. In M. Harandi, editor, Proceedings of the Symposium on Software Reusability, pages 131-135, Boston, Massachusetts, USA, May 1997. Software Engineering Notes, 22(3).

[TMC97] Scott Thibault, Renaud Marlet, and Charles Consel. A domain-specific language for video device driver: from design to implementation. In Proceedings of the 1st USENIX Conference on Domain-Specific Languages, Santa Barbara, California, October 1997.

[TCM98] Scott Thibault, Charles Consel, and Gilles Muller. Safe and efficient active network programming. In 17th IEEE Symposium on Reliable Distributed Systems, West Lafayette, Indiana, October 1998.

Last modified: 2003-09-25. - Jocelyn.Frechot@labri.fr - http://compose.labri.fr