Concrete syntax specification

A concrete syntax is a DSL’s interface that represents the abstractions defined in its abstract syntax. This interface should be convenient for human users as well as being easy to process by software components [167]. Most language specification experts focus on semantics and abstract syntax, paying little care and consideration to the design and specification of concrete syntax [1]. There are two major categories of DSL concrete syntax: i ) Textual DSLs that use linear textual notations based on ASCII, Unicode or other extended set of symbols; ii ) Graphical DSLs that use graphical shapes such as box-and-line diagrams [153,157,167]. DSLs are easily adopted by their user community when existing or familiar notations are adopted. Hence, a good choice of concrete syntax is important for DSLs to be accepted by the DSL users [153].

A DSL’s concrete syntax can be implemented using a language workbench. A lan- guage workbench is a software engineering tool that helps its users to efficiently cre- ate a language and enable integration with the tools to create models in these lan- guages [153, 157, 189]. Language workbenches reduce the effort required to develop DSLs and their IDEs [153]. Fowler [157] argues that a language workbench can be treated as a parser when used to define concrete syntax with its model-aware tooling against an existing semantic model. This prevents a semantic model from being locked in a specific language workbench [157]. There are several language workbenches that have been proposed to support the creation of DSLs [153,157,190,191].

Erdweg et al. [191] compared ten language workbenches according to their language engineering features that were classified into six categories: i ) Notation – these are features that determine how programs or models are presented to users; ii ) Semantics – these are features that support specification of language semantics; iii ) Editor support – these are feature that support syntactic and semantic editing of programs or models; iv ) Validation – these are features that support language-specific validation that are semantic in nature; v ) Testing – these are features that support the debugging of the language definition and the construction of the debuggers; vi ) Composability – these are features that support extension of existing languages and unification of multiple languages into a single language. They concluded that language workbenches provide adequate abstractions for implementing DSLs though the extent at which individual language workbenches support language engineering features vary widely [191]. Stoffel [192] compares three separate language workbenches according to their features. In another study, Vasudevan and Tratt [190] conducted a comparative analysis of four language workbenches for internal textual DSLs. Ribeiro et al. [193] also conducted a comparative analysis of three language workbenches for UML profile-based languages using qualitative criteria in separate study. These studies came to a conclusion that language workbench features vary widely such that selection of a particular language workbench should be based on the nature of the project at hand [190,192,193]. Though language workbenches vary in terms of their features and function, they present us with a unique opportunity that can be exploited by supporting the efficient implementation of a CIG DSL with its related tooling for authoring and maintaining CIGs.

Metaedit+, initially proposed by Smolander et al. [194] out of the MetaPHOR research laboratory, is a commercially available language workbench that can be used for imple- menting DSLs [195,196]. Though Metaedit+ has been widely used in the industry for over two decades [197], it uses a proprietary structure definition that makes the models and languages constructed with not portable to other language workbenches and edi- tors [198]. A further drawback of Metaedit+ is that it is a commercial platform that requires a pricy licence to operate.

Meta Programming System (MPS) is an open source language workbench, being de- veloped by Jetbrains, that supports many advanced features for creating graphical DSLs [153, 189]. MPS structure definition is proprietary though the language work- bench is open source. Voelter et al. [153] argues that MPS’ structure definition does not implement any acceptable industry standard though it is conceptually close to [199] Ecore, a model structure definition standard of the Eclipse Modelling Framework (EMF). Since MPS language workbench is limited to the creation of graphical DSLs [200], it may not suit textual DSL use cases such as support for rule-based CIG modelling. Another drawback of the MPS language workbench is that it currently only supports tooling for the IntelliJ IDEA IDE as it uses a proprietary structure definition [153,201].

Spoofax is an open source Eclipse-based language workbench, developed out of the University of Delft, that can be used for creating textual DSLs and tooling for use with the Eclipse IDE [153, 202]. Spoofax uses a structure definition called A Term that is based on a generic tree structure whose textual notation can be used for exchanging data between tools [153]. Spoofax lacks a mechanism that can easily reuse implementations by referencing existing DSL definitions [192].

Intentional Domain Workbench (IDW) is a commercially available language workbench that can be used for creating graphical DSLs that is conceptually similar to MPS [153, 203]. Not many details about IDW are available due to its commercial nature [204]. Xtext is a widely adopted open source language workbench for creating textual DSLs [153, 205,206]. Xtext uses EMF [199] open standards for its structure definition which allows its resulting DSL definitions and tooling to be highly interoperable with existing IDEs such as Eclipse and Intellij IDEA [153,207]. Xtext may not be as advanced as MPS but its Eclipse Modelling Platform ecosystem avails a large number of addons that enable sophisticated DSL environments [153]. Xtext can be exploited when creating a CIG DSL due to its open source nature and the usage of open standards in its DSL structure definitions.

A DSL needs to be properly integrated into its target information system platform in order to be useful to its user community. The section that follows discusses the methods that can be used to integrate a DSL with its target information system platform.