Richard A. O'Keefe
Thu Aug 24 03:26:56 CEST 2006
Robert Virding <> 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)
=> (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
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