JCrete2013:DSL Patterns
| DSL Patterns and experiences | |||
|---|---|---|---|
| Convenor: Marcus Schulte | |||
Participants:
| |||
Summary:
There was a very interesting talk about internal and external DSL. The audience agreed it is important to build an intermediary (abstract syntax tree) representation. For internal DSLs there was a discussion about Scala's case class feature, especially the ability to blend your custom DSL with the host language's collection library and control structures, much like one would do in Lisps with S-expressions. We looked at examples for nice internal DSLs
DSLs are mostly used (and most valuable) to developers. It's important to keep your target audience in mind and aim for maximal readability. It's good practice to start with putting fluent API on top of your domain model (or an underlying, more minimal API) rather than starting with some syntax/parsers. Even in the presence of IDE features like "inject language" to support external DSL's, internal DSLs were considered superior because they integrate more smoothly with surrounding metadata (like table-/entity-names for SQL). Scala's parser combinators are nice for meta-data rich external DSLs but they can become very slow especially when a lot of backtracking happens. JetBrains MPS found its niche in embedded development and as an important tool for internal development. For wider use it suffered from the lack of a "nice" textual representation of the syntax tree. Syntactic sugar in the host language (like the ability to omit dots and parentheses) does not guarantee (or even facilitate) developing good internal DSLs. Internal DLS are great for setting up test preconditions. Builders construction-DSLs are used for tests by most participants but some also use it in production code and are happy with it. Evolving DSL's which are published to the general public is just hard. One may have to write converters or provide transition periods in which both versions work. Debugging external DSL's can be desirable (workflow) - otherwise one is back to log-statements. An intermediate representation of the parsed language production (AST, execution plan) is again considered very helpful here. Ambiguities are hard but sometimes necessary because avoiding them would make a DSL unduly verbose. | |||
| Recommendations:
No recommendations provided. | |||
