For writing DSLs, consider the excellent speak of cgrand at the conj :
(not= DSL macros)
Here are the slides: http://speakerrate.com/talks/4895-not-dsl-macros
Yes, I saw the slides. I disagree with the speaker, at least, from
what I could see from the slides.
If you could argument more, this could be the start of an interesting thread ...
The arguments seems to be that
1) DSLs are not general purpose or turing complete
That depends. Axiom had an internal DSL that was basically
a sugar-coated lisp with a python-like syntax. It was both
general purpose and turing complete. A large portion of the
DSL was implemented in macros.
2) Users don't want a DSL
In work my users want a DSL. It enable them to write their
specifications in their language. I do a trivial paren-shift
(since they write F(x) rather than (F x)) and I can implement
their specification directly using macros. The macros are context
sensitive so they expand differently in different environments.
I generate XML, assembler, and lisp using the F macro.
This allows me to communicate directly to my users because they
hardly notice the paren-shift. We can be sure that the DSL
statements match the spec.
In another project I modified the lisp readtable so that, with
a combination of macros, the user could write python-like surface
syntax and lisp could read and execute it without a parser. The
user did not know the implementation was lisp. Macros allowed me
to rewrite the "parse tree" so it expanded into proper lisp.
In either case you could argue that "users did not know they were
using a DSL so they couldn't have wanted it". However, a DSL is
an implementation technique rather than something users would want.
3) macros add complexity
I'm at a complete loss to explain this. I use macros like
(with-open-file, (while-protected, (maybe, (destructure,
(spadcall, (seq, (lazy-eval, and many more to encapsulate
useful control structure. For example, the seq macro allows
an early exit from deeply nested code, essentially being a
well-shaped goto. The spadcall macro encapsulates a compile
time lookup in a static table and rewriting its argument to
insert fixed integer array indexes turning an apparent function
call into an array lookup. A "send" macro on a uniprocessor
compiles to a stack push but on a multicore it compiles to a
protected message queue append.
A well-chosen set of macros can create and support any special
kind of programming paradigm such as object-oriented, aspect-oriented,
message-passing, blackboarding, pattern-matching, and any
other idea that you like. If you're a Java programmer you could
write a "with-singleton" macro, or many other types of macros
that support the Booch "patterns" (why a lisper would WANT to
support Booch patterns is beyond me but...).
Macros, used properly, give amazing power, clarity, and flexibilty.
I've been writing them for many years.
I have never met a native Lisp programmer who would have created
the slide deck I saw. Native Java programmers have no equivalent
construct to macros (no, decorations are not macros) so they would
find macros complex, limited, and obscure.
Tim Daly
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
