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




         Present by: Tyler Netherland
Introduction are domain specific languages
  Many computer 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:


        DSL                   Application Domain
        BNF                   Syntax Specification
        HTML                  Hypertext Web Pages
        MATLAB                Technical Computing
        SQL                   Database Queries
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
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
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
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
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
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
Pattern Classification
 Decision
 Analysis
 Design
 Implementation
 Deployment (not discussed)
 A pattern used in one phase does not effect patterns
 used in other phases
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
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
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
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
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
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
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
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)
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
 Domain consists of Resources, behavior, and services
 Commonalities (status and rate)
 Variabilities (atomic vs compound)
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
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
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
Pattern Classification: Design
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
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
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
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
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
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
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
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.
Review
 DSLs are important and can be benefitial
 Patterns for decision, analysis, design and
 implementation