Re: Issue: LET-TOP-LEVEL (version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 3 Mar 88 12:15:58 PST
    From: Pavel.pa@Xerox.COM

    Dave says:
    ``Think about this nonsensical program:

      (let ((x (big-computation-that-returns-22/7)))
	(defmacro foo (y) `(list ,x ,y))
	(defun bar (z) (foo (1+ z))))

    (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know
    that?''

    This is just the issue that I addressed in my first message on this topic.  When
    you define a macro with a non-null closed-over environment, it is clear that the
    compiler cannot know how to evaluate the expansion function.  It is therefore
    reasonable to assume that the compiler cannot expand uses of that macro during
    the same compilation that encounters the DEFMACRO form.  If you want a macro
    like this, you must put the DEFMACRO in a separate file, compile and load that
    file, and then compile any uses of the macro.  This may be very reasonable for
    some applications.  

Right.  The problem is, do you really want the definition of Common Lisp
to say that a DEFMACRO defines a macro that can be used in the same
compilation "sometimes"?  "Sometimes" means it can be used if the body
of the macro doesn't reference any captured free identifiers, but not if
it does, unless the use is in a context where expansion happens at load
time instead of compile time.  Ick.

I'm fairly sure that we went through this line of reasoning in 1983 or so,
and that's what led to the present restriction in the first paragraph on
CLtL page 145, as the lesser of two evils.

    This style [captured free identifiers referenced in macro expander
    functions] doesn't disgust me and I see no reason not to support it.

It doesn't disgust me either.  The problem is the inconsistency you get
when a language supports both that style and the style of putting macro
definitions in the same file as macro invocations.  This problem is
compounded by Common Lisp's present vague semantics of compilation, but
I think even with a crisp semantics of compilation, it would be a
problem; I might be wrong about that, depending on what the crisp
semantics said about "top level."

I'd rather not outlaw either style, but so far I don't see how to make
them coexist.  I would not support changing Common Lisp incompatibly to
add the one style at the expense of outlawing the other, just because I
think incompatible changes are rarely warranted at this stage in Common
Lisp's life.