nested backquotes

[Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 14 Nov 88 09:11:39 PST
    From: Don Cohen <donc@vaxa.isi.edu>

    I think I understand your description (I think you left out a quote or
    two in the last element).  Furthermore, I strongly suspect (but have
    not yet proven) that it is equivalent to mine.  If so, my explanation
    seems easier to understand. 

You said: 
  "I don't see how to interpret CLtL to mean this (innermost backquote
   expanded first??)"  

I was just explaining the behavior of readers (that you determined
"experimentally") did conform to CLtL.  I thought you decided that CLtL
did not define the case of nested backquotes unambiguously.  I was just
pointing out that CLtL's rules defining the interpretation of nested
backquote cases *are* well-defined.  I don't claim that the rules are an
example of pedagogic clarity, or that your explication isn't easier to
understand, I was just showing you how CLtL's rules work.

The rule (in concise form) is: Expand the innermost backquote first,
always using the outermost comma.

The rule itself is simple.  In more complicated situations the
productions are ugly, taking many steps, and your model probably
describes the behavior more clearly.  I don't know.  I haven't tried to
prove that your model is equivalent to CLtL's rule, but intuitively they
seem equivalent.

If you understand CLtL's rule now, then you can use your model with more
confidence, since your original problem seemed to be that you didn't
know how to derive the behavior of readers from the specification in
CLtL.  

If you can prove that your model is equivalent, and if it is accepted
that your model is a clearer and cleaner explanation, then your model
should probably be included in a future backquote specification as a
useful guideline.
 
				The only problem was that you evidently
    did not understand what "matching" meant.  It was very simple and did
    NOT require expanding the inner backquotes.  Let me rephrase the model
    and see if you agree that it gives the same results as yours.  

    Pretend that comma (comma@) reads like quote - ,x = (COMMA x) except
    that an expression may not be in the scope of more commas than backquotes.
    Similarly, suppose that backquote reads as the symbol BACKQUOTE consed
    onto the next read.  So ``(a ,s ,',d ,,f `(,g)) reads as
    (BACKQUOTE BACKQUOTE a (COMMA s) (COMMA (QUOTE (COMMA d)))
	       (COMMA (COMMA f)) (BACKQUOTE ((COMMA g))))
    Now in order to evaluate that expression we find all forms that are
    in the scope of as many COMMAs as BACKQUOTEs.  We discard the leading
    BACKQUOTE and replace such expressions (along with the matching COMMAs)
    with their values.  In this case, the d and f are in the scope of 2 of 
    each.  The result is
    (BACKQUOTE a (COMMA s) (COMMA (QUOTE 4)) (COMMA 7) (BACKQUOTE ((COMMA g))))
    Evaluating this would similarly give something like
    (a 3 4 7 (BACKQUOTE ((COMMA g))))

    If you don't believe this model is equivalent please send me a 
    counterexample.  (The only thing I can see won't work is if something
    EVALUATES to a list containing the symbols BACKQUOTE or COMMA, 

The evaluation does not occur at read-time, unless there's a #,, but
then you can't pass ","'s up, so I don't think this is relevant.
								    and I
    think we can pretend that's impossible, even though it's precisely what
    I really WANTED to do!)