[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.