[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: donc@vaxa.isi.edu, greenwald@STONY-BROOK.SCRC.Symbolics.COM*Subject*: nested backquotes*From*: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Mon, 14 Nov 88 13:27 EST*Cc*: common-lisp@sail.stanford.edu*In-reply-to*: <8811141711.AA04256@vaxa.isi.edu>

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

**References**:**nested backquotes***From:*Don Cohen <donc@vaxa.isi.edu>

- Prev by Date:
**nested backquotes** - Next by Date:
**nested backquotes** - Previous by thread:
**nested backquotes** - Next by thread:
**nested backquotes** - Index(es):