Creating Domain-Specific Languages by Composing Syntactical Constructs

Abstract

Creating a programming language is a considerable undertaking, even for relatively small domain-specific languages (DSLs). Most approaches to ease this task either limit the flexibility of the DSL or consider entire languages as the unit of composition. This paper presents a new approach using syntactical constructs (also called syncons) for defining DSLs in much smaller units of composition while retaining flexibility. A syntactical construct defines a single language feature, such as an if statement or an anonymous function. Each syntactical construct is fully self-contained: it specifies its own concrete syntax, binding semantics, and runtime semantics, independently of the rest of the language. The runtime semantics are specified as a translation to a user defined target language, while the binding semantics allow name resolution before expansion. Additionally, we present a novel approach for dealing with syntactical ambiguity that arises when combining languages, even if the languages are individually unambiguous. The work is implemented and evaluated in a case study, where small subsets of OCaml and Lua have been defined and composed using syntactical constructs.

Resolvable ambiguity: principled resolution of syntactically ambiguous programs

“…Many (though not all) of the ambiguities that arise are resolvable, whereby our implementation produces suggested resolutions. One interesting example (originally from [31]) is that of nested match-expressions. OCaml ignores whitespace and uses longest match to disambiguate nested matches, thus the following code has a type error:…”

“…In our previous work [31] we also create languages through composition and show ambiguity errors to users. However, the errors merely present a shallow view of the ASTs of the alternatives, no suggested resolutions, which are instead left for future work.…”

“…A key concept in software engineering is that of compositionality: making a greater whole by composing smaller pieces. When implementing a programming language this can take the shape of language composition [10,18,30,31,40]: composing smaller language fragments to create a larger language. However, this approach brings its own set of challenges.…”

“…This is a natural approach given that most literature describes this as the singular way to handle ambiguity [3,13,21,38,43]. Following our previous work [31] we take a slightly less drastic approach: we merely reject ambiguous programs, similarly to [14,16]. This means that grammar composition is less likely to be problematic because grammar ambiguity is not automatically a problem.…”

“…Previous approaches that handle ambiguity do so by showing each valid (localized) AST [14,16,31], with the expectation that the user figures out how to resolve the ambiguity, typically using grouping parentheses. This is quite useful for a language designer, but less appropriate for an end-user; the AST is an implementation detail, and it may not be possible for an end-user to disambiguate the program.…”