Re: lexical list

[markf]

    From: Pavel_Curtis.PARC@xerox.com
    To: dfried@iuvax.cs.indiana.edu
    Cc: rrrs-authors@mc.lcs.mit.edu
    Message-Id: <900319-144349-1501@Xerox>


	From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
	Subject: lexical list
	Date: Mon, 19 Mar 90 16:42:45 -0500

	if `(,+) expands to (list +), does
	(let ((list (lambda args (write "hello"))))
	  `(,+))
	also write "hello"?
	Is this a bug or a feature?
	.. Dan

    Since `(,+) is, more-or-less, required to read as (quasiquote ((unquote
    +))), the real question is whether or not the expansion of the
    QUASIQUOTE macro should leave LIST free in its expansion.  I believe
    that it should not and, further, that the various proposals being
    discussed by the macros subcommittee would handle this just fine,
    allowing the expansion to use LIST without getting that reference
    captured.

According to my understanding of r4rs and the ieee standard,
quasiquotations are syntax for constructing list and vectors. They are
not macros and the expansion of '(,+) into (list +) is really only
conceptual. Therefore, an implementation which treats quasiquote as a
macro must be hygenic.

    A more interesting question, to my mind, is the value of the following
    expression:

	    (let ((quote car))
	      '(a b))

    I believe that the value of this expression should be the list (A B),
    whereas the value of the expression

	    (let ((quote car))
	      (quote (a b)))

    should (clearly?) be the symbol A.  That is, in the language of the
    now-passe syntactic closures proposal, the syntax '<datum> should be
    parsed by the language processor as a syntactic closure of the
    expression (quote <datum>) in the initial syntactic environment.

Again, according to the standards, quote is syntax for creating
constants. If you treat it as a macro it must be hygenic. The
standards also state that '<datum> is the same as (quote <datum>).

    Of course, a similar story should hold for the expression `<datum>. 
    There is room for disagreement about the "," and ",@" constructions,
    depending upon your view of auxiliary syntactic keywords, like ELSE and
    =>.

    Once one says that this is true, though, there remains the question of
    What the READ procedure does with such constructions.  Recall that
    language processors need not use READ for their scanning and parsing...

I'm not sure that READ is really relevant to the issues.

Excuse me if Pavel's argument is about what he would like the
semantics of these expressions to be. My comments were on what I think
the semantics currently are.

-Mark