Richard A. O'Keefe
Thu Aug 24 03:26:56 CEST 2006
Robert Virding <robert.virding@REDACTED> wrote:
Being a lisp programmer I must say that I have never before heard the
term "quasi-programming". Back-quote yes, but quasi-programming no.
I think someone has got confused with where "quasi" attaches.
What Common Lisp calls backquote is called quasiquote in Scheme.
Common Lisp says that `x ,x and ,@ are legal input forms, but
leaves undefined what they read as. So you *can* rely on what
will happen to them IF treated as Lisp code, but you can*not*
rely on what they'll look like if read as data, which pretty much
stuffs up any attempt to do your own processing.
In contrast, Scheme explicitly defines that
`x => (quasiquote X)
,x => (unquote X)
,@REDACTED => (unquote-splicing X)
where the obvious rules derive X from x, so you *can* write portable
Scheme code that reads Scheme code as data and knows what to expect.
(This is odd, because Scheme is not otherwise known for portability.)
Now the back-quote macro (it is a macro in lisp)
In fact Common Lisp has *two* kinds of macros: macros that are expanded
by the evaluator (= compiler and/or interpreter) and macros that are
expanded by the reader. Backquote (quasiquote) is the second kind,
which creates certain problems for name capture.
1. It allows you to write down a literal pattern for what you want to
build and only mark what is to be evaluated.
2. It allows you to splice in lists into your pattern with ,@REDACTED
Backquote is pretty much the *perfect* tool for creating XML.
I note that a similar feature has been bolted onto C in 'C (tick-C),
and that there's a Java preprocessor offering a similar feature for
constructing Java source code, as part of annotation-driven code
generation (the annotation part of this is now standard, albeit with
different syntax, in Java 1.5; as far as I know, which isn't very far,
the code generation part isn't).
More information about the erlang-questions