Domain-specific language

A domain-specific language (English domain-specific language, DSL for short ) is a formal language that is particularly suitable for a specific problem area (called the domain) designed and implemented. When designing a DSL you will strive to achieve a high degree of specificity problem: the language should be able to represent all the problems of the domain and can represent anything that is outside the domain. Thus they can be operated by domain experts without special additional knowledge.

The opposite of a domain-specific language is a general purpose programming language, such as C and Java, or a general-purpose modeling language such as UML.

  • 4.1 Definition of language
  • 4.2 Creation of records
  • 4.3 Evaluation of sets

Benefits

Among the advantages of DSL compared to the use of a general programming or specification language

  • Less redundancy
  • Declarative description of facts
  • Better readability
  • Less technical code
  • Domain-specific, static validation ( only external DSLs )
  • Easy to learn, due to the limited scope

End users can use DSLs, because they can be more easily learned than all-purpose programming languages. One speaks here of End User Development.

Disadvantages

  • In niche languages ​​or proprietary DSLs: lack of language standards, certification opportunities, free implementations, free or commercial libraries, literature, discussion forums etc.
  • Effort for learning a new language in a relatively limited scope of the language; inability or willingness of users to privately educate in the language
  • Risk that the user must make many development tasks ( Review, debugging, runtime measurement, ...) in the language of the generated code due to missing or unsuitable tools for DSL
  • Risk of lock-in with internal binding to the own tool development or external binding to the providers of tools for a niche language
  • Risk that the option to develop a new language or to use, leading to insufficient effort to other viable alternatives, such as the creation of comparable appropriate abstractions in the languages ​​used so far
  • Effort to determine the requirements for the new language, the definition of syntax and semantics, and the implementation and maintenance of tools ( editors, compilers, debuggers, static code checker, test environments, test coverage determination, metric tools) that are required for use of the language
  • Difficulty in identifying the needed long-term characteristics of speech: Requires the language of a module concept, the ability to define subroutines or data types, the representation of inheritance or interfaces or generic programming, or integration with code written in other programming languages?
  • Risk of creeping development of language in a general programming language, because the claims rise to the language and the language to be extended with new concepts
  • Difficulty of finding the appropriate level of abstraction

Types of DSLs

We distinguish between internal ( embedded ) DSL's and external DSLs.

Internal / embedded DSLs (internal DSL)

A subset of domain-specific languages ​​represent the internal DSLs is ( engl. internal DSL or embedded domain specific language), use the essential components of the language implementation of their host language. This implementation effort is reduced. An internal DSL is always a proper subset of a more general language.

Prominent representatives of internal DSLs are:

  • Rake (the make for Ruby )
  • Xunit frameworks
  • A domain- specific UML2 profile ( stereotypes, stereotype properties and constraints )
  • A domain- specific XML schema ( elements, restrictions )
  • Lisp -based DSLs

External DSLs (external DSL)

An external DSL is a from scratch defined language. Both the concrete syntax and the semantics can be defined here. External DSLs are therefore considered as a flexible and expressive. Until now, creating external DSLs in the past still associated with much effort, so today there are very good tools that greatly simplify the development of external DSLs.

Prominent examples of external DSLs are:

  • SQL
  • Regular expressions.

Phases of use

DSL is a formal language, and can thus be mechanically supported. While internal DSLs to define, use and evaluation of DSL are supported by existing tools (compiler, XML parser, interpreter XMI ), new tools need to be created for external DSL approaches.

Definition language

First of all, the alphabet ( domain-specific keywords ) of the DSL must be set and the domain-specific sentence formation rules.

Creating compositions

In the next phase domain experts to create sentences that conform to the alphabet and the set of formation rules, and to specify the technical conditions in your problem area.

Analysis of sentences

After the experts have created their specifications, it is important to evaluate this machine and automated further editing. A DSL can be transferred by means of a domain transformation into another DSL to further process the technical problem there. Eventually, however, the range of DSL is left and you transferred a domain-specific specification in a generic specification and can then be converted using standard tools in a problem solving this.

The domain-specific specification is transformed to the following species to another DSL, or translated into a generic specification:

  • By code generators
  • By interpreter
  • Or by using a compiler.

Tools

  • AMMI - FAW GmbH
  • DEViL - University of Paderborn
  • DSL Tools for Visual Studio
  • Eclipse Xtext (part of openArchitectureWare )
  • Eclipse GMF
  • EMFText
  • OOMEGA TMK ( Textual Modelling Kit)
  • Intentional Software
  • MetaEdit - MetaCase
  • Meta Programming System - JetBrains
  • Monti Core
  • YML
  • Lisp
General-purpose programming language Rake (Software) Make (software) Profile (UML) Interpreter (computing) Domain-Driven Design Integrated Authority File
245199
de