Implementing Closed Domain-Specific Languages

Abstract

A closed domain-specific language (DSL) is a stand-alone, declarative language designed to provide powerful and flexible software solutions specialized to a particular application domain. The users of a closed DSL are expected to be engineers or designers expert in the the- ory and techniques of their application domain, but who may be naive as programmers and who may not have the expertise, time, or inclina- tion to design their own software. A good DSL will capture both the nomenclature and the semantics of the application domain. We contrast closed DSL’s with open DSL’s, which are also useful, but for a different community of users. An open DSL denotes crucial abstractions of an application domain directly in the notation of a wide-spectrum programming language, possibly enriched with syntactic extensions. It supports the semantics of the application domain through a specialized library of combinators, usually written in the host language, although they may also be provided by linkage to a foreign-language library. Open DSL’s are popular with computer scientists, for whom the ability to extend the DSL by writing new combinators has a high value, and for whom the syntactic quirks of the host language and the nuances of its type system present little difficulty. For domain experts who are not computer scientists, the benefits of programming “under the hood” have less attraction and an invitation to interpret an obfuscatory error message can be daunting. Hence, interest in techniques by which closed DSL’s can be easily implemented remains high. We advocate defining the semantics of a closed DSL in terms of a uni- versal set of semantics combinators which form a structure algebra over a suitable domain. The combinator set may include constructors and destructors of algebraic data types. By exchanging the domain of the combinator algebra for a domain of abstract machine states, one auto- matically derives an implementation of the DSL in terms of byte code instructions for an abstract machine. The correctness of this implementa- tion is proved by showing coherence of the operational, abstract machine semantics with the denotational semantics. Advantages of this approach are that the “library” of semantics combina- tors is independent of the particular DSL to be implemented. The effort required to implement a semantics combinator library and to prove its coherence with respect to a denotational semantics can be amortized over multiple uses to implement a variety of DSL’s. A combinator-based im- plementation is also amenable to improvement by aggressive, automatic program transformation. Furthermore, the underlying abstract machine can easily be implemented on a new host architecture or via a platform- independent assembly language such as ‘C’. We compare this approach with several other approaches that have been taken to implement DSL’s. The design of suitable type systems and in- telligible error reporting remains a challenging issue. Users of a DSL are less interested in a programmer’s notion of types, which abstract the underlying computational semantics of the DSL, than in types that characterize the crucial abstractions of their application domain.