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

[Dan L. Pierson <pierson@mist>]

    Date: Tue, 1 Mar 88 13:24:19 PST
    From: Pavel.pa@Xerox.COM
    Subject: Re: Issue: LET-TOP-LEVEL (version 1)
    To: cl-cleanup@sail.stanford.edu
    
Please excuse my regrinding of your message where the lines didn't fit
after being indented.

    First, I would claim that this is a ``clarification'' as opposed
    to an ``addition''.  I see no language in CLtL to support the
    belief that DEFUN can only be used in certain scopes.  This
    reminds me of the debate over whether or not the compiler is
    required to be reentrant; of course it is, for the same reason
    that MAP is, for example: it's just another function with a
    particular contract.
    
The CLtL reference is page 66, 5.3 Top-Level Forms:
"It is not illegal to use these forms at other than top level, but
whether it is meaningful to do so depends on context.  Compilers,
for example, may not recognize these forms at other than top-level
contexts."

    In any case, I don't oppose the proposal because I think it's important for
    implementors to support this style.  I have some other comments, though.
    
    Why does the proposal not cover all of the defining forms?  In
    particular, why not DEFMACRO?  It makes just as much sense for the
    expansion function to be a closure.  Of course, the compiler will not
    be able to expand uses of that macro later in the same file, since it
    can't provide the proper lexical environment to the expansion
    function, but that just means that this style would have to be used in
    a separate file that is loaded before compilation of uses of the
    macro.  The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc.
    
I may have gotten confused here, my thinking was that since MACROLET
ignores lexical bindings that DEFMACRO should too.  I don't feel
strongly about this though.

    I not particularly happy with the explicit use of the term
    ``top-level'', but until Rob's compiler proposal gets a fair
    hearing, I don't see any way around it.
    
It's the current CLtL language, I'd be happy to see it changed.