Domain-specific Languages(DSLs)

Domain-specific languages (DSLs) are basically programming languages. But they are specifically targeted/tailored towards particular problem domains. Hence, it implies to the fact that DSLs are narrow in applicably unlike General-purpose programming languages(GPLs)[1]; hence, DSL precisely abstracts the domain and its semantics.  At the same time, being specific to a particular problem domains make it hard to reuse and adapt to a new problem domains or to the same evolving domain with new set of requirements.

problemdaomin
Figure 1:  DSLs are bridging the semantic gaps.

“Only way to manage complexity is to bring order to chaos”

Complex software systems consist of several concerns such as, performance, reliability , fault-tolerance, persistency. Hence, domain specialization is required to capture these concerns precisely and to perform various analyses specific to the domain. DSLs , thus reduce the complexity of complex systems  by providing high level linguistic abstraction through succinct syntax and by isolating concerns from one another which additionally results in highly cohesive sub-systems.  Following figure illustrate the fact that DSLs covers various concerns of complex software systems vertically rather than horizontally.

alt
Figure 2 :  Vertical domain specialization of DSLs in a complex system.

Although in recent years DSL-centric paradigm gets wider-applicability in various application domains due to the increase of domain specialization, the fundamental ideas[2] of DSLs existed  long before.As we were discussing in this blog, the inherent implementation strategies of DSLs warrant re-thinking the software process involved in DSLs development. To a large extent, success of a DSL depends on  the cost-effectiveness of the end product. We believe that it can only be achieved through modularizing definition of DSLs and by promoting reusability of the existing language constructs. Different aspects even when beginning a DSL development thus require careful considerations.

Key Properties  of  a DSL

  1. Coverage
  2. Expressivity
  3. Completeness
  4. Portability
  5. Support for evolution
  6. Quality of the generated artifacts.

Types of DSLs

Primarily, DSLs can be categorized into following categories–

  • Implicit DSLs  or Explicit DSLs
  • Textual DSLs  or Visual DSLs

    Basic Components of a DSL

    Alike GPLs, a DSL is constructed with the following primary components.

    1. Syntax definition formalism for defining syntax.
    2. A parser to parse the syntax of DSL and construct Abstract Syntax Tree(AST) or underlying model. ( however, visual DSLs does not require  parsers as AST can be constructed from the end-users’ specification).
    3. Model Transformer. It performs several model-to-model transformation such as, dusugaring , normalizing , decorating. As such, it annotate more context to AST.
    4. Afterwards, Semantic Analyzer performs static consistency checking.
    5. Code Generators. Final artifacts are generated through model transformation and string interpolation. In several DSLs, during code generations or in earlier phases, a meta-model is created. Afterwards, artifacts are generated by utilizing this meta-model. This way of creating a meta-model and generating artifacts from it promotes robust and maintainable code generator along with quality outcomes. Complex systems may require additional tuning, which can be facilitated via Code Customization  ( we will discuss about it in later blog posts) .

      phase
      Figure 3 : Various phases of step-by-step transformations and finally, code generation using a DSL [3].

    Aside above mentioned components, support of rich development environment is increasingly becoming important to get expected productivity from a DSLs. Several language workbenches[3] thus are providing rich support from various editor services such as code folding , syntax highlighting , reference resolving, syntax completion.

    [in-progress]

    References

    [1] Spinellis, D. (2001). "Notable design patterns for domain-specific languages." J. Syst. Softw. 56(1): 91-99.
    [2] Landin, P. J. (1966). "The next 700 programming languages." Commun. ACM 9(3): 157-166.
    [3]L. Kats, E. Visser.The Spoofax Language Workbench . Rules for Declarative Speci?cation of Languages and IDEs.



    • No Comments