Domain-specific programming language

From Wikipedia, the free encyclopedia

You have new messages (last change).

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), such as C or Java, or general-purpose modeling languages like UML. Examples of DSLs include spreadsheet macros, YACC for parsing and compilers, Generic Eclipse Modeling System for creating diagramming languages, 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 by various names:

  • Little languages
  • Macros (in reference to the macro feature found in spreadsheets, word processors, and other applications, and not to the powerful programming language macros, which 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.

Contents

[edit] Usage patterns

There are several usage patterns for DSLs:

  1. DSLs which operate standalone, and are called via direct user operation (often on the command line or from a Makefile), like GraphViz.
  2. 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.
  3. 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.
  4. 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.

[edit] 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. A DSL can be either a visual diagramming languages, such as those created by the Generic Eclipse Modeling System or the Generic Modeling Environment, programatic abstractions, such as the Eclipse Modeling Framework, or textual languages. 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.

[edit] Requirements

[edit] 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 have two important design goals that contrast with those of general-purpose languages like C or Java:

  • DSLs are less comprehensive.
  • DSLs are much more expressive in their domain.

[edit] Idioms

In programming, idioms are methods imposed by programmers to handle common development tasks, e.g.:

  • Ensure data is saved before the window is closed.
  • Before conducting expensive tests, perform cheap tests that can rule out need for expensive tests.
  • Edit code whenever command-line parameters change because they affect program behavior.

General purpose programming languages rarely support such idioms, but DSLs can describe them, e.g.:

  • A script can automatically save data.
  • A smart test harness can learn what good tests are.
  • A DSL can parameterize command line input.

[edit] Example

UNIX shell scripts give a good example of a DSL for data organization. They can manipulate data in files or user input 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.

Although notorious for its use of Greek letters and special symbols, the APL programming language, with its interactive session, provided for rapid design and deployment of interactive and scriptable domain specific languages. These usually, by design, required no special input consideration from its users such as APL keyboards or fonts.

Wiki markup is another example of a domain-specific programming language. The goal of the language is to output a web page using a minimal set of instructions.

[edit] Applications in software engineering

There has been a great deal of interest in Domain-Specific languages to improve the productivity and quality 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]. 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.

[edit] 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.

[edit] 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.

[edit] See also

[edit] External links

[edit] References

  1. 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.
  2. 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
  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
Retrieved from "http://en.wikipedia.org../../../d/o/m/Domain-specific_programming_language.html"
In other languages