Comparison between Internal and External DSLs via RubyTL and Gra2MoL [chapter]

Jesús Sánchez Cuadrado, Javier Luis Cánovas Izquierdo, Jesús García Molina
Computational Linguistics  
Domain Specific Languages (DSL) are becoming increasingly more important with the emergence of Model-Driven paradigms. Most literature on DSLs is focused on describing particular languages, and there is still a lack of works that compare different approaches or carry out empirical studies regarding the construction or usage of DSLs. Several design choices must be made when building a DSL, but one important question is whether the DSL will be external or internal, since this affects the other
more » ... ects of the language. This chapter aims to provide developers confronting the internal-external dichotomy with guidance, through a comparison of the RubyTL and Gra2MoL model transformations languages, which have been built as an internal DSL and an external DSL, respectively. Both languages will first be introduced, and certain implementation issues will be discussed. The two languages will then be compared, and the advantages and disadvantages of each approach will be shown. Finally, some of the lessons learned will be presented. Model-driven paradigms are based on three basic principles. Firstly, a software application is partially (or totally) described using models, which are high-level abstract specifications, rather than using solely a GPL. Secondly, these models are expressed with DSLs which are created by applying meta-modeling (i.e. the DSL abstract syntax is represented as a meta-model). Thirdly, automation is achieved by means of model transformations which are able to directly or indirectly transform models (e.g., DSL programs) into the final code of the application by creating intermediate models. Two kinds of model transformation languages are therefore needed (Czarnecki & Helsen, 2006) : model-to-model transformation languages, which allow us to express how models are mapped into models, and model-to-text transformation languages, which allow us to express how models are mapped into text (e.g., GPL code). Model-based techniques can also be applied in software modernization tasks, and a third kind of model transformation with which to extract models from legacy software artifacts (e.g., GPL code or a XML document) is then involved, which is normally called text-to-model transformation. A DSL normally consists of three basic elements: abstract syntax, concrete syntax, and semantics. The abstract syntax expresses the construction rules of the DSL without notational details, that is, the constructs of the DSL and their relationships. Meta-modeling provides a good foundation for this component, but other formalisms such as BNF have also been used over the years. The concrete syntax defines the notation of the DSL, which is normally textual or graphical (or a combination of both). There are several approaches for the semantics (Kleppe, 2008), but it is typically provided by building a translator to another language (i.e., a compiler) or an interpreter. Several techniques have been proposed for the implementation of both textual DSLs (Fowler, 2010; Mernik, Heering & Sloane, 2005) and graphical DSLs (Kelly & Tolvanen, 2008; Cook, Jones, Kent & Wills, 2007) . In this work we focus on textual DSLs, and particularly consider two kinds or styles according to the implementation technique used: external DSLs and internal DSLs. An external DSL is typically built by creating a parser that recognizes the language's concrete syntax, and then developing an execution infrastructure if necessary. An internal DSL, however, is implemented on top of a general purpose language (the host language), and reuses its infrastructure (e.g., concrete syntax, type system and run-time system), which is extended with domain specific constructs. The DSL is therefore defined using the abstractions provided by the host language itself. For instance, in an object-oriented language, method calls can be used to represent keywords of the language. Languages with a non-intrusive syntax (e.g., LISP, Smalltalk or Ruby) are well suited for use as host languages. A number of design decisions must be made when building a DSL, such as those related to its concrete syntax, how the language semantics is going to be defined and in which form (interpreted or compiled), or whether there will be an underlying abstract syntax. However, deciding whether the DSL will be internal or external will have an impact on the other aspects of the language. Making an effective choice between these two options therefore requires a careful evaluation of the pros and cons of each alternative. Some important aspects that should be evaluated are the following, which are related to the three elements of a DSL: abstract and concrete syntaxes, and semantics (executability and optimizations), and to quality criteria (extensibility and efficiency) and DSL tooling (tools for developing DSL and tools for using DSL). • Concrete syntax. Does the DSL require a specialized syntax? Is the host language syntax suitable for the DSL? How much effort is needed to embed the DSL in comparison to building the DSL from scratch? • Abstract syntax. In which cases might an abstract syntax be necessary, and in which is it possible to manage without it? How different is it to support an abstract syntax in each case? This last issue is related to the following aspect.
doi:10.4018/978-1-4666-6042-7.ch040 fatcat:ljbruxprx5a4nnlwexnqtvspt4