Domain-specific programming language
|
|
A domain-specific language (DSL) is a programming language designed to be useful for a specific set of tasks, in contrast to general-purpose programming languages. 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, which creates a visual representation of that graph as a result.
DSLs have also been called:
- Little languages
- Macros
- Application languages
- Very high level languages
DSLs tend to be focused on doing one sort of task well. For instance, GraphViz is designed to create images of graphs in a variety of formats, but within GraphViz there is no capability for accessing a network socket, receiving additional user input, or manipulating strings.
There are three usage patterns for DSLs:
- DSLs operate standalone, and are called via a direct user operation (often on the command line), like GraphViz.
- DSLs are called from more full-featured languages, like C or Perl, to perform a specific function, often returning the results of operation to the "host" programming language for further processing.
- 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 all three ways: 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.
| Contents |
DSLs in Context
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 extremely 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.
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 scripting or compiled programming 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) to 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 GPLs. 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[[1] (http://chacs.nrl.navy.mil/publications/CHACS/1998/1998heitmeyer-WIFT.pdf)]. 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 productivity, reliability, maintainability, portability and reusability.
- DSLs allow validation 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 efficiency when compared with hand-coded software.
Examples
See Category:Domain-specific programming languages for an exhaustive list.
External links
- DSL links from Lambda the Ultimate (http://lambda-the-ultimate.org/taxonomy/node/or/24)
- Martin Fowler on DSLs (http://martinfowler.com/bliki/DomainSpecificLanguage.html)
- Tim Menzies on DSLs (http://www.cs.pdx.edu/~timm/dm/dsl.html)
- Domain-Specific Languages: An Annotated Bibliography (http://homepages.cwi.nl/~arie/papers/dslbib/)
- One Day Compilers: Building a small DSL using OCaml (http://www.venge.net/graydon/talks/mkc/html/index.html)
- Notable Design Patterns for Domain-Specific Languages (http://www.dmst.aueb.gr/dds/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html)
- DSMForum.org: Industry cases and examples of Domain-Specific Modeling Languages (http://www.dsmforum.org)
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.