Domain-specific language topics

Usage patterns There are several usage patterns for domain-specific languages: ? processing with standalone tools, invoked via direct user operation, often on the command line or from a Makefile (e.g., the GraphViz tool set) ? domain-specific languages 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 ? embedded (or internal) domain-specific languages, implemented as libraries which exploit the syntax of their host general purpose language or a subset thereof, while adding domain-specific language elements (data types, routines, methods, macros etc.). The distinction between an embedded DSL and a generic library or API is fuzzy and mostly relates to stylistic and pragmatic concerns: most APIs are designed to expose their features in a straightforward and transparent way, rather than create a usable and distinctive 'language'. ? domain-specific languages which 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 domain-specific language is embedded into the host application ? domain-specific languages which are embedded into user applications (e.g., macro languages within spreadsheets) and which are used to execute code that is written by users of the application, dynamically generated by the application, or both. Many domain-specific languages can be used in more than one way.

Design goals Adopting a domain-specific language approach to software engineering involves both risks and opportunities. The well-designed domain-specific language manages to find the proper balance between these. Domain-specific languages have important design goals that contrast with those of general-purpose languages: ? domain-specific languages are less comprehensive. ? domain-specific languages are much more expressive in their domain. ? domain-specific languages should exhibit minimum redundancy according to the following subjective definition. Redundancy of a program is defined as the average number of textual insertions, deletions, or replacements necessary to correctly implement a single stand-alone change in requirements. For a language, this is averaged over programs in the problem domain. This measure is useful because, the smaller it is, the less likely that bugs can be introduced by incompletely implementing changes.

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 domain-specific languages can describe them, e.g.: ? A script can automatically save data. ? A smart test harness can learn what good tests are. ? A domain-specific language can parameterize command line input.