On 13-Apr-09, at 10:47 AM, Kouskoulas, Yanni A. wrote:
> I do understand David's explanation of his expectations (i.e. read
> top-level form, macro-expand it, and then compile it) and they do
> make sbcl's behavior seem reasonable. But from a usage perspective,
> I can see the reasonableness of clisp's behavior as well. So the
> question really comes down to what standard is being implemented, so
> one knows what one should be able to rely on to facilitate
What you're describing isn't CLISP's behaviour as much as that of its
interpreter. These semantics are pretty much impossible to support in
a compiler (especially since the spec mandates that all macros must be
fully expanded in compiled functions), and, indeed, CLISP's compiler
doesn't support them. You're using behaviour that's explicitly
undefined in the spec, precisely because of the different needs of
compilers and interpreters.
> I did some digging and found the part of the CLTL2 that made me
> think that I should be able to do this.
>> From http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node98.html
> "X3J13 voted in March 1989 (DEFINING-MACROS-NON-TOP-LEVEL) to
> clarify that, while defining forms normally appear at top level, it
> is meaningful to place them in non-top-level contexts. Furthermore,
> defmacro should define the expander function within the enclosing
> lexical environment, not within the global environment. "
No all that means is that the macro-expansion function should have
access to the enclosing lexical environment, e.g.
(let ((foo 42))
(defmacro foo (x)
is legal. The note does not mean that the macro is established in the
enclosing lexical environment; that's what MACROLET is for.