[pro] Lisp and DSLs

Alessio Stalla alessiostalla at gmail.com
Wed Jul 20 21:34:55 UTC 2011


On Wed, Jul 20, 2011 at 9:21 PM, Martin Cracauer <cracauer at google.com> wrote:
> I find that people have a wrong impression of what it means to have a
> domain specific language.
>
> For me, one of the greatest advantages of Lisp is literal data in
> code.  I don't have to write a complicated parser for some external
> data, I don't have to hook up a XML reader library to a bunch of
> callbacks and construct a graph or tree or whatever in those callbacks
> and then I have to write that graph in XML (ugh) with no programming
> help at all unless I pipe it through m4. In Lisp code I just write the
> graph, the entire thing, no matter how complicated.  And although it
> is Lisp source code it doesn't have to live in the source
> distribution, I can load an external file later.
>
> And it gets to use all the Lisp tools I have built for my application
> anyway, to help me construct that complicated data structure, without
> using m4.
>
> That does a lof of what many people mean when they say they need a
> DSL. What they really want is not to have to do a bazillion lines of
> code to hook up the ability to read complex structured real-world
> data.

I agree, that's one of the greatest advantages of DSLs in Lisp (so
called "internal" DSLs) versus "external" DSLs which seem to be
getting the most mainstream attention these days, with complex tools
to design parsers, editors and whatnot. Without even touching macros,
the Lisp reader and printer systems already provide invaluable tools
for reading and writing complex data, tools that other languages lack.
Macros can then help as a little syntactic sugar, to remove some
boilerplate, or to do some bookkeeping, or to move some computation to
compile-time (another huge win other languages completely lack). XML,
JSON, YAML etc. are so hyped because they introduce a little dynamics
in otherwise mostly static languages like Java, but they come with the
burden of libraries for parsing, writing, binding to objects, and have
trouble expressing shared structure.
Besides, in Lisp-based DSLs, it's generally easy or even trivial to
escape to Lisp when needed, to use e.g. conditionals or looping, two
basic programming language constructs that are lacking (and often
missed) in "data-oriented" languages like XML.
So, the code = data paradigm is really two-way: you can manipulate
code as data, but you can also treat data as part of the code, and the
latter point is often neglected.

Alessio




More information about the pro mailing list