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

SYMBOL-MACROLET



    Date: Mon, 10 Jul 89 18:50 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    [Common-Lisp removed in favor of more specific mailing lists.]

	Date: Mon, 10 Jul 89 13:49:20 PST
	From: goldman@vaxa.isi.edu
	To: common-lisp@sail.stanford.edu
	Subject: SYMBOL-MACROLET
	Message-Id: <8907102149.AA27155@vaxa.isi.edu>
    
	Is it the case that the expansion code for a symbol-macro, (unlike
	a lexical macro introduced with MACROLET) has not means to obtain
	the current lexical environment?
	neil

    It doesn't get to execute code in order to produce the expansion,
    so obtaining the environment would be meaningless.  The only question
    is, does it get the lexical environment of the binding-point or the
    usage-point. I posed a question like the following to several CLOS 
    implementors at the last X3J13 meeting.

     (DEFMACRO FOO () 1)
     (SYMBOL-MACROLET ((X (FOO)))
       (MACROLET ((FOO () 2))
	 X))

    Consensus seems to be that it is currently defined to return 2.

    I think some people consider this a feature, though I've not seen a
    serious example which shows why. Personally, I think it's a bug.
    I'd rather that it return 1.

This is no different from

     (DEFMACRO FOO () 1)
     (MACROLET ((X () `(FOO)))
       (MACROLET ((FOO () 2))
	 (X)))

which also returns 2.

If Common Lisp had syntactic closures, as proposed to be added to Scheme,
then it would be possible for the definition of X to specify whether
the FOO in the expansion is closed or free, i.e. whether the name FOO
is to be resolved in the environment where the macro was defined or in
the environment where the macro was called.

Since Common Lisp does not have syntactic closures at this time, it is
consistent and appropriate for SYMBOL-MACROLET to behave the same as
MACROLET.  I didn't say it was a feature, I only said it was consistent
and appropriate.