These reports were originally published in ;login: Vol. 23, No.1, February 1998. Conference on Domain-Specific Languages
SANTA BARBARA, CA
Summaries by Andrew J. Forrest
OVERVIEW USENIX held its first ever conference on the subject of Domain-Specific Languages (DSLs). The purpose of the conference was to bring together people who are interested in the idea that programming languages are first-class tools to exploit in the creation of software, and that the development of problem-appropriate computer languages is the basis for a valuable approach to software engineering. Although this conference was organized into seven sessions, each with a specific focus, a number of themes emerged, cutting across sessions and recurring in many presentations. Domain-Specific Languages The Ultimate Abstraction This theme holds that Domain-Specific Languages represent direct support for key abstractions in a programming domain. A DSL can represent an abstraction in a way that offers advantages when compared with other abstraction approaches, such as the use of libraries. Language as a First-Class Tool This theme presents language as a fundamental tool; it revolves around the idea that in many circumstances it is appropriate to create a new language rather than rely on the less specialized features of an existing general-purpose programming language. Domain Analysis and Design for DSLs A key step in the creation of a DSL, domain analysis is done to varying degrees of formality. The main question is "How does one pick the appropriate abstractions for the DSL to contain?" Is there a process for this? What is the relationship between the language designer and the domain expert(s)? Does the domain already have an accepted notation that suggests itself as a syntax for the DSL? DSL Implementation Framework This theme examines the various means by which a DSL can be implemented. Should a DSL be embedded in a larger, more general-purpose language (GPL)? Should it be implemented via a preprocessor? Or should an entirely separate implementation be developed? DSLs and Rapid Prototyping This theme occurs in two forms: DSLs support rapid prototyping because they tend to operate at a high level of abstraction; and rapid prototyping supports DSL creation by facilitating iterative design of the language. Compiler Support and Tools for DSLs Because DSLs are created more frequently than full GPLs, and because they may be changed more frequently, the need for compiler-compiler and other translator tools is greater with DSLs than with GPLs. It seems that the needs of DSL creators could influence compiler construction technology toward such benefits as more debugging, better debugging, support for specifying semantics, and more visualization. Advantages of DSLs Finally, there are many, many advantages to DSLs, such as notational convenience, certain type checking and global optimization opportunities, the ability to make additional safety guarantees, the potential for domain experts to program, the possibility of a variety of analysis, and the ability to capture an abstraction, thereby serving as an example of reuse. Regarding the conference as a whole: a very high proportion of attendees was present for the entire conference despite the pleasant weather and beachfront venue. Interest in the BOFs was so great that initial plans to run them concurrently were shelved in favor of a consecutive schedule, and the papers presented were of such uniformly high quality that the program committee was unable to single out one for special commendation! Overall, I believe the conference was a great success and would not be at all surprised if USENIX were to repeat it at some point in the future. See you there! KEYNOTE ADDRESS The Promise of Domain-Specific Languages Paul Hudak, Yale University Department of Computer Science Domain-Specific Languages: Some Definitions With help from a motley crew of animated agents residing in his laptop computer, Paul Hudak began his entertaining and thoughtful keynote address on the promise of Domain-Specific Languages. Hudak offered a framework for thinking about and working with DSLs, starting with a definition of the term itself: "A programming language tailored specifically for an application domain: it is not general purpose but rather captures precisely the semantics of the domain, no more and no less." He quickly followed with a definition of "application domain," which he accomplished by way of example, citing simulation, lexing and parsing, CAD/CAM, hardware description, text/pattern matching, computer music, and database queries, among others. To add to the list, Hudak said, one merely needs to reflect on the question: "How many papers have you seen with a title such as XXX: A Language for YYY?" Hudak also offered a second definition of a DSL: "the ultimate abstraction of an application domain; a language that you can teach to the intended user in less than a day." This definition relies on the observation that the intended user of a DSL is probably already well versed in the semantics of its domain and needs only a suitable notation with which to program. In case you think DSLs are something new, you could ponder the list of popular and successful DSLs and their domains that Hudak presented:
Advantages and Disadvantages of the DSL Approach Chief among the advantages of the DSL approach to software development is higher programmer productivity because programs written in a DSL tend to be more concise, quicker to write and maintain, as well as easier to (automatically) reason about. Furthermore, although it sounds oxymoronic, DSL programs can sometimes be written by nonprogrammers. Hudak observed that these motivators are the very ones that drove the adoption of high-level general-purpose languages in the first place! Of course, the DSL approach is not without challenges, too: performance may be poor because high-level languages are sometimes inefficient; there may be unacceptable start-up costs associated with the development of a DSL; a "Tower of Babel" may result if every domain acquires a specific language; the temptation to add features incrementally to a DSL can lead to bloat; and perhaps most important, designing and implementing languages (well) is a very hard task typically requiring two to five years for a new one. All of these issues represent possible obstacles that we need to overcome in order to more readily enjoy the benefits of DSLs. A Recommended Approach to DSL Development Given his experience with implementing and using a number of DSLs, Hudak distilled these recommendations for building software with a DSL:
Hudak observed that, although syntax and semantics are well treated in current and prior DSL development, tools often receive short shrift. The Embedded DSL: An Implementation Approach To overcome the weakness in tool support and to address some of the earlier noted disadvantages, Hudak advocated an approach to DSL development whereby the DSL is embedded in an existing, more general-purpose programming language an Embedded DSL or "DSEL." A DSEL inherits general-purpose features from the enclosing language, the "host," as well as that language's existing tool set as a base. This frees the DSL designer who is implementing the DSL to concentrate on semantic issues and then provide domain-specific optimizations and extensions for an existing tool set. Hudak also advocated the use of metaprogramming tools such as transformation systems or partial evaluators to recover performance and practicality that might otherwise be sacrificed by the embedded approach. As advantages of the DSEL approach, Hudak cited rapid DSL design, increased changeability, familiar look and feel, reuse of infrastructure, a reduction in language bloat, and because whatever formal methods are applicable to the host language are applicable to the DSL, the possibility of using algebraic/denotational semantics. A DSL tends to share the same limits and face the same problems as the underlying host language, so Hudak cautioned that the choice of host language should be made after the abstract design of the DSL so that it can be made based primarily (if not entirely) on its suitability for hosting the particular DSL rather than on some other considerations. The Lightweight DSL: An Implementation Refinement Hudak introduced a refinement to the embedding approach called the Lightweight DSEL, which is a "pure" embedding. He noted that this approach requires a fairly powerful base language, one with higher-order functions, automatic memory management, syntactic extensions, flexible evaluation, and a flexible type system. In fact, in his experience implementing DSLs in Haskell, Hudak has made significant use of the higher-order functions, lazy evaluation, type classes, monads, and infix syntax features of Haskell. According to Hudak, the definitive way to embed a DSL within Haskell is to treat the DSL as an abstract data type for which an implicit interpreter represents the semantics. In this way, equational reasoning can be used to verify key algebraic properties of the DSL. Conclusion Hudak concluded by saying that DSLs are a good thing. Embedded DSLs and lightweight DSELs can be good things, but we need more and better tools to help with the design and implementation of DSLs. He also said that there should be a shift in emphasis in tool design from syntax to semantics, that the science of computer science has a role to play here. Algebraic/denotational semantics, modular interpreters, modular program execution tools, extensible type systems, and program transformation/partial evaluation were all mentioned as fruitful areas for this work. Hudak never explicitly addressed the teaser that introduced his abstract for the keynote address, namely, "Are domain-specific languages (DSLs) the long-awaited silver bullet of software engineering?" However, he did argue cogently that DSLs have value and that embedding can be an excellent approach to the implementation of DSLs. In addition, he framed the entire conference with his definitions of a DSL and his worthwhile recommendations for the design and implementation of DSLs. To see more, consult his official and personal home pages:
<https://WWW.CS.Yale.edu/HTML/YALE/CS/faculty/hudak.html> REFEREED PAPERS Session: Domain-Specific Language Design Each of the three presenters in this session introduced a problem domain, characterized some of its unique aspects, and described the design goals of an appropriate solution. In each case, the author showed how insight progressed to design and related the language design to the implementation architecture. Service Combinators for Web Computing Luca Cardelli, Digital Equipment Corporation, and Rowan Davies, Carnegie Mellon University Cardelli and Davies based this work on observations about both the unique characteristics of the World Wide Web and the way it is used. On the Web, documents may be unavailable or slow to transfer. People compensate with interesting retrieval strategies involving multiple connections and preemptive behavior based on transfer rates. These strategies are not expressible via existing distributed paradigms, such as remote procedure calls. Cardelli and Davies therefore began with the view that the Web is a new and peculiar kind of computer, the "Berners-Lee Machine," and set out to derive a language for programming it. The result is a nascent language of service combinators for which a Java-based interpreter exists and a useful look at how one might go about designing a DSL. The language can be used to express typical human Web-browsing strategies because it allows direct references to the important characteristics of the Berners-Lee machine (including transfer rate). The authors offered a succinct formal semantics for the language and proved the correctness of certain optimizing transformations. This language of combinators was implemented as a set of composable Java functions rather than as a full-fledged language with its own unique concrete syntax. The authors argued that this implementation approach can be a good prototyping technique because it provides a performance benefit, eliminates the possibility of parsing or lexing errors at runtime, and reuses the syntax of the host language and therefore the front end of that language's compiler. As Davies noted, this is a general technique suitable for any Domain-Specific Language that is to be translated via an interpreter embedded in a
|
 Need help? Use our Contacts page.
First posted: 30th January 1998 efc Last changed: 30th January 1998 efc |
|
Conference index