Wile, David S.. Supporting the DSL spectrum. CIT. Journal of computing and information technology, 9(4):263-287, 2001.
Posted by Ricky T. Lindeman on 30/06/2010 16:23, last updated on 30/06/2010 16:27 (Public)
Title: Supporting the DSL Spectrum
Author: Wile, David S.
Wile states that DSL usage is very effective for users if they can write specifica- tions in the same jargon as is used in the domain. However, commitment to a DSL approach can be rather expensive, depending on the level of infrastructure support provided for a product. In this paper Wile will discuss various DSL approaches and will evaluate them using several issues important for DSL as well as GPL development.
In Section 2 Wile discusses DSL advantages, section 3 mentions DSL design approaches. Section 4 discusses the different issues that can arise in the devel- opment process. And section 5 compares the various approaches with respect to how they handle these issues.
The second section discusses several advantages that can be identified when users create programs using a DSL. Firstly, a DSL program is more comprehen- sible and easier to write leading to a greater productivity. Secondly, a category of advantages that are identified by Wile exist due to the fact that the natural internal representations for the linguistic constructs are attuned to the needed tool support. This statement is only partially true, as not all DSL implemen- tation approaches maintain their internal representations. Thirdly, the domain experts without programming experience can write programs reducing the costs. However, programming effort is shifted to DSL development requires greater ex- pertise than the normal program support staff. Wile notes that the usage of these skills depends on the type of support that will be provided for the use of a domain specific language as discussed in the remainder of the paper.
In the third section Wile discusses three DSL approaches: Full language design, language extension and COTS-based. These approaches will be evalu- ated using four common aspects of language design: structure, configuration, constraints and behaviors. The domain of “satellite ground controllers” will be used as an example throughout the paper.
With a full language design the designer has full control over the syntax and the semantics of the DSL. This allows the DSL to have a syntax that will match the domain notations and often a syntax editor can be generated for free. According to Wile dealing with these syntactic and semantic concerns is fairly expensive. This approach can be compared with the interpreter, compiler or application generator as identified by Mernik et al. [2].
A less expensive approach is the language extension approach: An exist- ing language is specialized with domain specific data types and operators that will fit the domain. This approach is comparable with the the preprocessor, embedding or extensible compiler/interpreter approach as identified by Mernik et al. [2]. Wile uses Haskell and Java to illustrate this technique, chosen as current representatives of the OO-programming approach and the declarative programming approach, respectively.
It is questionable if the Java approach can be genuinely be called a lan- guage extension approach. In general Java is very verbose and this is reflected in the example given by Wile. Typical Java-statements, such as constructing new objects, clutter the program. Furthermore, the given program fragment is not even valid Java syntax. The implementation proposed by Wile more or less represents a general application library approach. The satellite DSL also supports statements to define behavior, it is however untold if this would be specified in standard Java syntax or a specialized syntax.
On the other hand, the Haskell approach leads to a more concise DSL because of its compact syntax. However, implementing a DSL in Haskell is less trivial due to the use of monads needed to implement the behavioral part of the DSL. But for Haskell Wile does discuss how behavior is implemented.
Wile shortly discusses generic programming techniques wherein functions have arguments that are programs, types, type constructors, class hierarchies, or even grammars. Such a program, also called an application generator, can take a specification language as input and can create a Haskell program as in the previous paragraph.
The third approach Wile introduces is the COTS-approach, in this approach a Common Off-The-Shelf (COTS) product is used to express the structural aspects of a DSL. This approach would result in an internal DSL [1]. But is this approach really different from the previous approach as both approaches reuse existing components but add a domain specific flavor?
Wile discusses an implementation that uses Microsoft Access as COTS- product to host a DSL. Microsoft Access, a database management system, can perfectly be used to define elements and constraints, but Wile lacks to discuss how behavior can be defined and executed.
XML as DSL is used as a second example of the COTS-based approach. XML schema’s specify a DSL program in an abstract-syntax-based way but a separate XML interpreter has to be created which defines the semantics. The verbose nature of the syntax makes it however hard for humans to write and read XML.
The third example uses Microsoft PowerPoint as DSL. The graphical features of PowerPoint allow it to be a visual editor for domain specific languages with domain specific editing tools.
In the fourth section Wile identifies three kinds of issues that make DSL support difficult:
Each issue is split up into multiple concerns and in section 5 Wile evaluates each approach with respect to a subset of the concerns identified in the DSL- specific and GPL support issues. The pragmatic support issues are not used in the evaluation as they should only influence the decision to favor one approach over the other. Unfortunately, Wile does not make it clear if the presented list of concerns is complete and why certain concerns are evaluated and others are not. Wile presents a table with a row for each concern and a column for each mentioned example per approach. The table o have an error, as the con- cerns “Persistence” and “Versions” are listed under pragmatic support issues while in the previous section they previous were listed as GPL support issues. Furthermore, Wile notes that the evaluation is mostly based on personal expe- rience with the approaches, the table can thus be biased or incorrect if more appropriate techniques exists.
Values in the cells for the DSL-specific issues refer to “how well different language aspects can be expressed in the given technology, not how readily the semantic support behind these sub-languages can be expressed”. According to this statement the costs to implement such a concern are not reviewed. But the remainder of the concerns refer to how difficult it is to provide support for the activity, not whether it is already provided by the technology.
The full language design approaches score the best in the DSL-specific issues category and COTS-approaches score the worst as they are usually not meant to be used to host a DSL. In the GPL support issues category full language design approaches score average and the other approaches score below average. Although the table scores were based on personal experience from Wile, it re- flects the reality. A full language design approach is comparable to designing a GPL, for which mature tools and frameworks exist. A full language design approach is however not always the best choice when low implementation costs are preferred over the implementation of GPL support issues. A COTS-based approach can be chosen when the users are familiar with a COTS-product.
In the remainder of the section Wile discusses each of the eleven issues, but some statements need clarification. Firstly, for the structure issue Wile states that for Java a form-based interface can be created to edit attributes of objects. But is the form-based interface approach still an example of a full language design approach? Secondly, when relationships need to described Wile does not mention that Java is an object orientated language that uses references to objects. These references can be used to define relationships between objects. Lastly, according to Wile type checking in the language extension approach is hard when the type checker of the host language is insufficient, because the inter- nal abstract syntax representation is inaccessible. However, an implementation approach based on an extensible compiler or interpreter can indeed reason over the abstract syntax representation.
In his conclusion Wile states that he hopes to have convinced the reader of three statements:
The first statement is rather vague, as it is unclear what Wile means with: “doing something with programming languages”. Wile probably refers to the COTS approach, in which existing software applications are used instead of creating or modifying an existing programming language, but it could also mean that a DSL can be used as a specification language. The discussion of the three DSL approaches in this paper should be enough to prove the validity of the second and third statement.
In his paper Wile has given three approaches for providing DSL support as well as three categories of issues that are important in DSL development In contrast with the three approaches by Wile, Mernik et al. identified six different imple- mentation patterns [2]. Most of the patterns are also discussed by Wile and can be placed under the appropriate approach, except for the extensible com- piler or interpreter pattern which is not mentioned by Wile but can be seen as a language extension approach. If Wile was aware of this pattern several issues in the GPL support issues category that require an abstract syntax representation would be evaluated differently as an extensible compiler or interpreter allows access to such a structure.
[1] Martin Fowler. Domain specific languages. http://martinfowler.com/ dslwip/, December 2009. Accesed on 2 December 2009.
[2] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv., 37(4):316–344, 2005.