Domain-specific programming language

A domain-specific programming language (domain-specific language, DSL) is a programming language designed to be useful for a specific set of tasks. This is in contrast to general-purpose programming language (general-purpose language, GPL), for example PL/1 or ADA, or general-purpose modeling languages like UML. Examples of DSLs include spreadsheet macros, YACC for parsing and compilers, Csound, a language used to create audio files, and GraphViz, a language used to define directed graphs, and create a visual representation of that graph.

DSLs have also been called:

Little languages
Macros. ("Macro" here refers to the feature found in spreadsheets, word processors, and other applications, and not to programming language macros. Programming language macro systems, especially powerful systems like that found in Common Lisp, are frequently employed to implement DSLs).
Application languages
Very high level languages

DSLs focus on doing one sort of task well. For instance, GraphViz is designed to create images of graphs in a variety of formats, but GraphViz lacks the capability to perform some basic tasks, e.g. accessing a network socket, receiving additional user input, or manipulating strings.

Usage Patterns

There are several usage patterns for DSLs:

DSLs which operate standalone, and are called via direct user operation (often on the command line or from a Makefile), like GraphViz.
DSLs which are implemented using programming language macro systems, and which are converted or expanded into a host General Purpose Language at compile-time or read-time.
DSLs are called (at runtime) from programs written in General Purpose Languages like C or Perl, to perform a specific function, often returning the results of operation to the "host" programming language for further processing. Generally, an interpreter or virtual machine for the DSL is embedded into the host application.
DSLs are embedded into user applications, like macro languages within spreadsheets, and they are used to execute code that is written by users of the application, dynamically generated by the application, or both.

Many DSLs can be used in more than one way: GraphViz can be run on a command line, there are Perl modules which output GraphViz data, and GraphViz has been embedded into other applications as a visualization component.

DSLs in Context

A DSL is created specifically to solve problems in a particular domain and is not intended to be able to solve problems outside of it. In contrast, General-purpose programming languages are created to solve problems in many domains. General Purpose Languages are necessarily Turing Complete.

The domain can be also a business area. E.g., Life insurance policy DSL developed internally in large insurance enterprise, combat simulation DSL, salary calculation DSL, billing DSL, etc.

A DSL is somewhere between a tiny programming language and a scripting language, and is often used in a way analogous to a programming library. The boundaries between these concepts are quite blurry, much like the boundary between scripting languages and general-purpose languages.

DSLs are languages (or most often, declared syntaxes or grammars) with very specific goals in design and implementation. For instance, the command line utility grep has a regular expression syntax which matches patterns in lines of text. The sed utility defines a syntax for matching and replacing regular expressions. Often, these tiny languages can be used together inside a shell to perform more complex programming tasks.

The line between DSLs and scripting programming languages is somewhat blurry, but DSLs often lack low-level functions for filesystem access, interprocess control, and other functions that characterize full-featured programming languages, scripting or otherwise. Many DSLs do not compile to byte-code or executable code, but to various kinds of media objects: GraphViz exports to PostScript, GIF, JPEG, etc, where Csound compiles to audio files, and a ray-tracing DSL like POV compiles to graphics files. A computer language like SQL presents an interesting case: it can be deemed a DSL because it is specific to a specific domain (in SQL's case, accessing and managing relational databases), and is often called from another application, but SQL has more keywords and functions than many scripting languages, and is often thought of as a language in its own right, perhaps because of the prevalence of database manipulation in programming and the amount of mastery required to be an expert in the language.

Further blurring this line, many DSLs have exposed APIs, and can be accessed from other programming languages without breaking the flow of execution or calling a separate process, and can thus operate as programming libraries.

Some DSLs expand over time to include full-featured programming tools, which further complicates the question of whether a language is domain-specific or not. A good example is the functional language XSLT, specifically designed for transforming one XML graph into another, which has been extended since its inception to allow (particularly in its 2.0 version) for various forms of filesystem interaction, string and date manipulation, and data typing.

In Model Driven Engineering many examples of DSLs may be found like OCL, a language for decorating models with assertions or ATL a domain specific transformation language. However languages like UML are typically general purpose modeling languages.

To summarize, an analogy might be useful: a Very Little Language is like a knife, which can be used in thousands of different ways, from cutting food to cutting down trees. A DSL is like an electric drill: it is a powerful tool with a wide variety of uses, but a specific context, namely, putting holes in things (although it might also be used to mix paint or remove screws). A General Purpose Language is a complete workbench, with a variety of tools intended for performing a variety of tasks. DSLs should be used by programmers who, looking at their current workbench, realize they need a better drill, and find that a specific DSL provides exactly that.

Requirements for DSLs

Design Goals: Adopting a DSL approach to software engineering involves both risks and opportunities. The well-designed DSL manages to find the proper balance between these two. DSLs are:

Less comprehensive than general-purpose languages like C or Java.
Much more expressive in their domain.

Idioms: In programming, idioms are methods imposed by programmers to handle common forms, procedures.

E.g. Ensure data is saved before the window is closed.
E.g. Before conducting expensive tests, perform cheap tests that can rule out need for expensive tests.
E.g. Having to edit code every time command-line parameters change because they effect behavior of your program.

There is (usually) no support for these idioms in general purpose programming languages. DSLs can be used as tools to describe these idioms.

E.g. Script to automatically save data.
E.g. Smart test harness that learns what good tests are.
E.g. Parameterizing command line input via DSL.

Example of a good DSL for data organization: UNIX Shell Script

With UNIX shell scripts, data in files or user input can be manipulated in many different ways. Domain abstractions and notations include streams (such as stdin and stdout) and operations on streams (such as redirection and pipe). These abstractions combine to make a robust language to talk about the flow and organization of data.

The language consists of a simple interface (a script) for running and controlling processes that perform small tasks. These tasks represent the idioms of organizing data into a desired format such as tables, graphs, charts, etc.

These tasks consist of simple control-flow and string manipulation mechanisms that cover a lot of common usages like searching and replacing string in files, or counting occurrences of strings (frequency counting).

Even though UNIX scripting languages are Turing-complete, they differ from General Purpose Languages. There is no mechanism for creating complex data structures such as lists and trees. There is no support for object oriented design.

In practice, scripting languages are used to weave together UNIX tools that do small tasks like AWK (or gawk), ls, sort, wc, etc.

DSLs For Software Engineering

There has been a great deal of interest in recent years in Domain-Specific languages to improve the productivity and quality of software engineering.

In the domain of software engineering, DSLs could possibly provide a robust bed of tools for efficient software engineering. Such tools are beginning to make their way into development of critical software systems.

The SCR (Software Cost Reduction) Toolkit is an example of this^*. This toolkit is suite of utilities including a specification editor for creating a requirements specification, a dependency graph browser for displaying variable dependencies, a consistency checker for catching missing cases in well-formed formulas in the specification, a model checker and a theorem prover for checking application properties against the specification, and an invariant generator that automatically constructs invariants based on the requirements.

Advantages and Disadvantages of DSLs

Advantages

DSLs allow solutions to be expressed in the idiom and at the level of abstraction of the problem domain. Consequently, domain experts themselves can understand, validate, modify, and often even develop DSL programs.
Self-documenting code.
DSLs enhance quality, productivity, reliability, maintainability, portability and reusability.
DSLs allow validation at the domain level. As long as the language constructs are safe any sentence written with them can be considered safe.

Disadvantages

Cost of designing, implementing, and maintaining a DSL
Finding a proper scope
The difficulty of balancing between domain-specificity and general-purpose programming language constructs.
The potential loss of processor-efficiency when compared with hand-coded software. (But consider also the legend of John Henry.)

External links

References

Constance Heitmeyer. Using the SCR Toolset to Specify Software Requirements. Proceedings, Second IEEE Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, Oct. 19, 1998.
Diomidis Spinellis. Notable design patterns for domain specific languages. Journal of Systems and Software, 56(1):91–99, February 2001. doi:10.1016/S0164-1212(00)00089-3
Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Computing Surveys, 37(4):316–344, 2005. doi:10.1145/1118890.1118892

Domain-specific programming languages | Programming language classification

Domänenspezifische Programmiersprache | Langage dédié | Язык программирования предметной области

Gourt Home::Gourt :: Domain-specific programming language