Metaprogramming

[Richard A. O'Keefe]

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).