In this post on the PLT discussion list I asked:
What is all the fuss about how you can write DSLs in Lisp?
Everyone from thought-leaders to blog-posters to grandma’s are talking
about how Lisp is so great for DSLs.
About what are these people talking about? Because no one of said
people actually elaborate on any of this, of course, which leads me to
question their claims.
jrm provided the following excellent reply (mirrored here):
On 6/7/07, Grant Rettke wrote:
That said, when I think of a DSL think about letting folks write
"programs" like:
"trade 100 shares(x) when (time < 20:00) and timingisright()"
When I think about syntax transformation in Lisp I think primarily
about language features.
In order to talk about domain-specific languages you need a definition of what a
language is. Semi-formally, a computer language is a system of syntax and
semantics that let you describe a computational process. It is characterised
by these features:
1. Primitive constructs, provided ab-initio in the language.
2. Means of combination to create complex elements from the primitives.
3. Means of abstraction to control the resulting complexity.
So a domain-specific language would have primitives that are specific
to the domain
in question, means of combination that may model the natural combinations in
the domain, and means of abstraction that model the natural abstractions in the
domain.
To bring this back down to earth, let's consider your `trading language':
"trade 100 shares(x) when (time < 20:00) and timingisright()"
One of the first things I notice about this is that it has some
special syntax. There
are three approaches to designing programming language syntax. The first is to
develop a good understanding of programming language grammars and parsers and
then carefully construct a grammar that can be parsed by an LALR(1), or LL(k)
parser. The second approach is to `wing it' and make up some ad-hoc syntax
involving curly braces, semicolons, and other random punctuation. The third
approach is to `punt' and use the parser at hand.
I'm guessing that you took approach number two. That's fine because you aren't
actually proposing a language, but rather you are creating a topic of
discussion.
I am continually amazed at the fact that many so-called language designers opt
for option 2. This leads to strange and bizarre syntax that can be very hard to
parse and has ambiguities, `holes' (constructs that *ought* to be expressable
but the logical syntax does something different), and `nonsense'
(constructs that
*are* parseable, but have no logical meaning). Languages such as C++ and
Python have these sorts of problems.
Few people choose option 1 for a domain-specific language. It hardly
seems worth
the effort for a `tiny' language.
Unfortunately, few people choose option 3. Part of the reason is that
the parser
for the implementation language is not usually separable from the compiler.
For Lisp and Scheme hackers, though, option 3 is a no-brainer. You call `read'
and you get back something very close to the AST for your domain specific
language. The `drawback' is that your DSL will have a fully
parenthesized prefix
syntax. Of course Lisp and Scheme hackers don't consider this a drawback at
all.
So let's change your DSL slightly to make life easier for us:
(when (and (< time 20:00)
(timing-is-right))
(trade (make-shares 100 x)))
When implementing a DSL, you have several strategies: you could write
and interpreter for it, you could compile it to machine code, or you
could compile it
to a different high-level language. Compiling to machine code is unattractive
because it is hard to debug, you have to be concerned with linking,
binary formats,
stack layouts, etc. etc.
Interpretation is a popular choice, but there is an interesting
drawback. Almost all DSLs have generic language features. You
probably want integers and strings and
vectors. You probably want subroutines and variables. A good chunk of your
interpreter will be implementing these generic features and only a
small part will
be doing the special DSL stuff.
Compiling to a different high-level language has a number of
advantages. It is easier to read and debug the compiled code, you can
make the `primitives' in your
DSL be rather high-level constructs in your target language.
Lisp has a leg up on this process. You can compile your DSL into Lisp
and dynamically link it to the running Lisp image. You can `steal'
the bulk of the
generic part of your DSL from the existing Lisp: DSL variables become Lisp
variables. DSL expressions become Lisp expressions where possible. Your
`compiler' is mostly the identity function, and a handful of macros
cover the rest.
You can use the means of combination and means of abstraction as provided by
Lisp. This saves you a lot of work in designing the language, and it saves the
user a lot of work in learning your language (*if* he already knows
lisp, that is).
The real `lightweight' DSLs in Lisp look just like Lisp. They *are* Lisp. The
`middleweight' DSLs do a bit more heavy processing in the macro expansion
phase, but are *mostly* lisp. `Heavyweight' DSLs, where the language semantics
are quite different from lisp, can nonetheless benefit from Lisp
syntax. They'll
*look* like Lisp, but act a bit differently (FrTime is a good example).
You might even say that nearly all Lisp programs are `flyweight' DSLs.
