When and How to Develop Domain-Specific Languages

1. When and How to Develop Domain-Specific Languages Marjan Mernik, University of Maribor Jan Heering, CWI Anthony M. Sloane, Macquarie University ACM Computing Surveys, Vol 37, No. 4

2. Introduction Many computer languages are domain specific languages (DSLs) as opposed to general purpose languages (GPLs) Aid in writing programs in specific domains DSL�s have been around since the late 1950�s (BNF) Examples:

3. Introduction DSLs trade generality for expressiveness Offer gains in productivity Reduce maintenance cost Enable non-experts in the domain to more easily program applications DSLs enable reuse

4. Introduction With an application library (API providing classes and methods), a GPL could act as a DSL but� Domain-specific notations are difficult to express in a operator notations provided by GPLs Domain-specific constructs and abstractions cannot always be mapped well to functions and objects (i.e. traversals and error handling) A DSL can be used to analyze, verify, optimize, parallelize and transform DSL constructs. The GPL could not because it source code patterns are too complex or not well defined. DSLs need not be executable

5. Introduction Still, many DSLs are actually domain-specific embedded languages (DSELs) DSELs are made with GPL APIs. DSELs are often the most cost effective solution

6. Introduction: Executability of DSLs Well-defined execution semantics HTML Input language of an application generator ATMOL: atmospheric modeling Application generator compiles the DSL, still executable More declarative and less well-defined execution semantics Not executable but useful for application generation BNF: purely declarative, but can be an input language for a parser generator DSL not meant to be executable Domain-specific data structure representations Benefit from editors, analyzers, consistency checkers

7. Introduction: DSLs and Reuse Contribute to software engineering by allowing reuse of software artifacts i.e. grammars, source code, software designs and domain abstractions Application generators enable programmers to reuse semantic notations in the DSL without having to perform detailed domain analysis DSL APIs Reuse of source code

8. Scope of the Paper �When and How� to develop DSLs is difficult to decide DSL development is hard Need domain and language development knowledge DSL development techniques are more varied than those for GPLs Providing training materials, language support, standardization and maintenance can be time-consuming Often the need for a DSL is not evident until much effort has been put into using a GPL. Therefore think of DSL development as an important step in software reengineering The paper identifies patterns in DSL development

9. Pattern Classification Decision Analysis Design Implementation Deployment (not discussed) A pattern used in one phase does not effect patterns used in other phases

10. Pattern Classification: Decision Helps answer �when� to develop a DSL Decision patterns are common situations in which developers in the past have successfully developed DSLs DSLs must offer more economical software development and maintenance Providing a quantitative analysis of the benefits is difficult

11. Pattern Classification: Decision Adopting an existing DSL is less expensive, but one which is appropriate could difficult to find and not well documented Improved software economics Enable software development by users with less domain knowledge and programming experience

12. Pattern Classification: Decision 1. Notation: are appropriate notations available? Transforming visual to textual notation Add user-friendly notation to an existing API or turn an API into a DSL 2. AVOPT (domain-specific Analysis, Verification, Optimization, Parallelization, Transformation) A DSL will allow these operations where a GPL usually will not

13. Pattern Classification: Decision 3. Task automation An application generator for the DSL can generate code that follows the same pattern 4. Product lines Software products lines share common architecture and common elements that can be specified with one DSL 5. Data structure representation Required data structures could be difficult to write and maintain with a GPL

14. Pattern Classification: Decision 6. System front-end DSL-based front-end can handle a system�s configuration and adaptation 7. Interaction DSL can help specify complicated and repetitive input (Excel macro language) 8. GUI constructs Implemented with DSLs

15. Pattern Classification: Analysis Identify the problem domain and gather knowledge Inputs are domain knowledge technical documents domain experts Existing GPL code Customer surveys Output Domain-specific terminology (vocabulary) Domain-specific semantics in abstract form

16. Pattern Classification: Analysis 1. Informal 2. Formal Outputs a domain model domain definition/scope domain terminology domain concepts feature model describing commonalities and variabilities in concepts and their interdependencies i.e. Feature Oriented Domain Analysis(FODA) 3. Extract from code

17. Pattern Classification: Ananlysis Variabilities indicate required information for specifying an instance of the system (variable) Commonalities define the execution model and primitives of the language (mandatory)

18. Pattern Classification: Ananlysis Example using FODA tries to recreate human behavior while accessing and manipulating web resources with slow tramissions The feature model: Represents hierarchical decomposition of features and their character (mandatory, alternative, optional) Defines semantics of features Gives feature composition rules describing valid and invalid combinations of features Provides reasons for choosing a feature

19. Domain consists of Resources, behavior, and services Commonalities (status and rate) Variabilities (atomic vs compound)

20. Pattern Classification: Design Need to consider the relationship between the DSL and existing languages the formal nature of the design description 1. Language Exploitation easy to implement and easy for users to use Piggyback: use existing language partially with domain features Specialization: restrict existing language Extension: extend existing language with new features

21. Pattern Classification: Design 2. Language Invention Completely new DSL with no existing commonalities with existing languages Difficult to develop and characterize Common design ideas such as economy of form and orthogonality are not necessarily right for DSL jargon

22. Pattern Classification: Design 1. Informal designs Natural language Easy to use 2. Formal designs Specification using one of the available semantic definition methods i.e. Regular expressions, attribute grammars, abstract state machines Difficult but help hash out potential problems before implementation

23. Pattern Classification: Design

24. Pattern Classification: Implementation When an executable DSL is designed the most suitable implementation approach should be chosen DSL specific techniques are less known The right technique will impact the implementation effort

25. Pattern Classification: Implementation 1. Interpreter DSL constructs are recognized and interpreted using a fetch-decode-execute cycle Good for languages with dynamic character or execution speed is not an issue Simple, easily extended, control over execution environment

26. Pattern Classification: Implementation 2. Compiler DSL constructs are translated to base language constructs and library calls Offers complete static analysis on DSL specification DSL compilers are application generators

27. Pattern Classification: Implementation 3. Preprocessor DSL constructs are translated into an existing language Static analysis is limited to that done by the base language processor

28. Pattern Classification: Implementation 4. Embedding DSL constructs are embedded in an existing language by defining specific abstract data types and operators Uses application libraries Have completed access to host language Operator overloading (C++) can be harmful to semantics

29. Pattern Classification: Implementation 5. Extensible Compiler Extends a GPL compiler with domain-specific optimization rules/code generation Compilers are usually difficult to extend 6. Commercial Off-The-Shelf Existing tools are applied to a specific domain 7. Hybrid A combination of the others

30. Pattern Classification: Implementation Interpreter/Compiler DSL syntax close to that used by experts Good error reporting AVOPT Large development effort; a complex language processor is needed Designing from scratch creates potential incoherencies Language extension is difficult because language preprocessors are not meant to be extended

31. Pattern Classification: Implementation Embedded Modest development effort (an existing implementation is reused) Usually produces a more powerful language since many features are given for free The host language infrastructure can be reused (debuggers) User training cost are usually lower since they may know the host language Syntax will not be optimal because host languages do not allow arbitrary syntax extension Overloading existing operators is confusing Error reporting is in terms of host language concepts and not DSL concepts Domain-specific optimizations and transformations are difficult. Efficiency is therefore reduced.

33. Review DSLs are important and can be benefitial Patterns for decision, analysis, design and implementation