Building Domain-Specific Embedded Languages

Paul Hudak. Building Domain-Specific Embedded Languages. ACM Computing Surveys, 28(4es):196, 1996. [doi]

Review: Building Domain-Specific Embedded Languages

Posted by Ricky T. Lindeman on 30/06/2010 16:22, last updated on 30/06/2010 16:27 (Public)

“Building Domain-Specific Embedded Languages”

Title: Building domain-specific embedded languages

Author: Hudak, Paul

Review and Summary

Hudak believes that domain specific languages are the “ultimate abstraction” when creating programming languages. In this paper Hudak outlines several techniques that according to his believe can lead to the effective development of a domain specific language. These techniques eliminate the problems encountered when a DSL’s evolves. Hudak assumes that a DSL should not be build from scratch, instead a GPL should be modified yielding a domain specific embedded language. Furthermore Hudak also assumes that the GPL has an interpreter, allowing the designer to concentrate on the semantics. However, according to Mernik et al. [2] syntax should be just as important as semantics, as it should be as close as possible to the notation used in the domain.

The remainder of the paper describes the result of using Haskell to build DSEL’s. Haskell is used by Hudak because it has several suitable features, but he also remarks that he can think of other features that do not exist in existing languages that could make things even easier. The features Hudak speaks of are left unknown to the reader but the Haskell specific features could be deduced from the sections discussing implementation details. These features would be the availability of monads to create modular interpreters and partial evaluation to optimize composed interpreters.

The choice to use Haskell as an example gives rise to the following question: How can this implementation be compared to an implementation using a non- functional, for instance an object orientated, GPL. Furthermore, with the focus on interpreters Hudak skips the field of extensible compilers.

Hudak discusses a DSEL in the domain of geometric region analysis which was used for a naval application. This experiment demonstrated the viability (non-programmers could understand a DSEL program) of the DSEL approach, but also its evolvability (different versions of the language were developed, each capturing more domain logic).

The previous mentioned DSEL was implemented using a modular monadic interpreter approach. Using this approach multiple interpreters could be layered upon each other leaving the code of the other interpreters unchanged, facilitating evolution of the DSEL. In addition to domain specific semantics also domain specific optimizations can be implemented in an interpreter incrementally and independently from each other as well as from the core semantics.

In the same fashion interpreter language support tools, such as debuggers or profiles, can also be implemented for DSL’s. The core interpreter can be instru- mented with different tools in such a way that they do not affect each other. The implementation specifics of a single instrumentation tool are however not clarified with a code example by Hudak. The actual implementation therefore remains vague.

The second useful Haskell feature is partial evaluation. Partial evaluation im- proves the performance of composed interpreters in two ways. First, a concrete tool can be created when specializing a tool generator to a tool specification. Second, when a concrete tool is specialized to the source of a program an in- strumented program is created. A later paper by Hudak [1] shows concrete facts about the optimizations due to partial evaluation.

Hudak used existing partial evaluation techniques and concludes they are not user-friendly, but fails to provide concrete evidence. Hudak suggests a semi-automated partial evaluation approach. But it is unclear which type of statement cannot be partially evaluated. Furthermore, giving the user more explicit control over the transformation process effects the modular interpreter approach. The transparency of the modular approach disappears when users have to specify transformation rules that effect multiple interpreter components and the evolution of an interpreter can lead to a change transformation rules.

Conclusion

Although the techniques listed by Hudak could definitely improve the develop- ment of domain specific languages, they are only applicable to DSEL’s imple- mented using an interpreter. Interpreters may result in less development costs, but cannot be compared to the execution speed a compiler offers. Combin- ing multiple modular interpreters has a positive effect on the maintenance of the domain-specific language, but a change in the core module still requires a modification of the surrounding layers.

References

[1] Paul Hudak. Modular domain specific languages and tools. In ICSR ’98: Proceedings of the 5th International Conference on Software Reuse, page 134, Washington, DC, USA, 1998. IEEE Computer Society.

[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.