Explicit definition of backquote

[Jon White <JLW@SU-AI.ARPA>]

In-reply-to: your message of  2-Jun-85  11:02 EDT

MacLisp may have been the first implementation to use macro wrappers for the
target of the various "backquote" readmacros; it was motivated by the desire
to use the programable "prettyprinter", which had a very simple readmacroinverse
facility.  The goal was to have read/print do for backquote what it was doing
for singlequote.  Later, the Lispm (which had backquote first) switched from a 
direct expansion into basic primitives (like, QUOTE, CONS, APPEND etc)
to the use of internal, semi-unpronouncable names which were copies of
these primitives, primarily to retain a modicum of the structure of the
original text (I don't think it succeeds in all cases, as does the pdp10
MacLisp and NIL code.  By the way, MacLisp's wrapper names are also
quite unpronounceable -- but then, MacLisp has no package system.)

In defense of using eval-time macros, rather than going directly to
"efficient" primitive code, one may notice that CL requires a macro
expansion hook (CLtL, page 152), with which one may smoothly implement
the equivalent of the MacLisp MACROMEMO macro cacheing scheme [this
is somewhat equivalent to Interlisp's cacheing of expansions in the
hashtable CLISPARRAY].  With a very modest amount of time spent on
tuning the evaluator, there should be no hesitation to use macros freely 
in CL; in fact, with a compile-time-only "optimizer", it's quite feasible
to retain full input syntax, while compiling something quite different,
something which has been "optimized" to the hilt.

Even a vanilla implementation, wrappers or not, for the next manual would
be of immense help, and could fullfill your suggestion:
    If we really want to do this, it should be sufficient to define
    S-expression forms that the various backquote character macros COULD
    expand into, and that programs can generate to get the same effect.  We
    don't have to require implementors to actually use these in processing
    backquoted expressions.
Frankly, I think such a suggestive coding, in Lisp, would be more easily
understandable than the formal specification of CLtL pages 349-351.  

This may have more value than one would think at first.  A few years back,
someone in the Interlisp community decided to re-invent the backquote facility
in a more "Interlispy" fashion, and spent three years getting it wrong.  The 
test case was some doubly-nested (not triply-nested!!) code taken from Bob 
Kern's original implementation of DEFSETF for MacLisp/NIL.   About every six
months, this individual would proffer yet another version of the newly-invented
substitute for backquote, and I would have to grovel over the output on the
test case to see why it was wrong.  Sometimes the code produced was grossly 
erroneous (unbound gensyms as free variables!) but most often it would
CONS when it should have LIST'd, or CAR when it should have CDR'd; and
the only way to check it was to compare it with the normalized form
produced by pdp10 MacLisp.

We need the CL equivalent of that MacLisp version -- a standard by which
other, alleged backquote implementations may be measured.

-- JonL --