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 programming language 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.
=DSLs in Context=
A DSL is created specifically to solve problems in a particular domain (Software Engineering) and is not intended to be able to solve problems outside of it. In contrast, General-purpose programming languages (GPLs) are created to solve problems in many domains. GPLs are necessarily Turing Complete.
A DSL is somewhere between a Tiny programming languages 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 operating system shell to perform more complex programming tasks.
The line between DSLs and 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 GPL 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.
There is (usually) no support for these idioms in general purpose programming languages. DSLs can be used as tools to describe these idioms.
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 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 programming language (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 ( 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 efficiency when compared with hand-coded software. (But consider also the legend of John Henry (folklore).)
=Examples=
See for an exhaustive list.
=See also=
*Domain-specific modelling *General-purpose programming language (contrast)
=External links=
*[http://lambda-the-ultimate.org/taxonomy/node/or/24 DSL links from Lambda the Ultimate] *[http://martinfowler.com/bliki/DomainSpecificLanguage.html Martin Fowler on DSLs] *[http://www.martinfowler.com/articles/languageWorkbench.html Martin Fowler on Language Workbenches] *[http://www.cs.pdx.edu/~timm/dm/dsl.html Tim Menzies on DSLs] *[http://homepages.cwi.nl/~arie/papers/dslbib/ Domain-Specific Languages: An Annotated Bibliography] *[http://www.venge.net/graydon/talks/mkc/html/index.html One Day Compilers: Building a small DSL using OCaml] *[http://www.dsmforum.org DSMForum.org: Industry cases and examples of Domain-Specific Modeling Languages] *[http://www.usenix.org/publications/library/proceedings/dsl97 Usenix Association: Conference on Domain-Specific Languages (DSL 97)] *[http://www.usenix.org/publications/library/proceedings/dsl99 Usenix Association: 2nd Conference on Domain-Specific Languages (DSL 99)] *[http://www.nolics.net Nolics.net 2005] -- Object-relational mapping combined with Domain Specific Languages (for Visual Studio 2005)
=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. [http://www.spinellis.gr/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html Notable design patterns for domain specific languages]. Journal of Systems and Software , 56(1):9199, February 2001. [http://dx.doi.org/10.1016/S0164-1212(00)00089-3 doi:10.1016/S0164-1212(00)00089-3]|
|