Re: Issue MACRO-ENVIRONMENT-EXTENT

[David N Gray <Gray@DSG.csc.ti.com>]

>     The extent of macro environment objects is related to EVAL-WHEN because macro
>     expanders may wish to return forms which contain environments as quoted
>     constants.  
> 
> I am convinced that this should be ruled out, and that CLOS made a mistake
> here.  (Incidentally the part of CLOS that says this is in chapter 3, the
> accepted part of CLOS does not say anything about the expansion of the
> macros is.)

Except for ENSURE-GENERIC-FUNCTION, which is defined in chapter 2 with an
:ENVIRONMENT argument, and referenced on page 2-28 as part of the
semantics of DEFGENERIC.  Maybe this function should have been in chapter
3 instead?  Should it be removed from the standard?

>     Requiring environments to have indefinite extent has
>     problems for CLOS because at compile-time it wants to create remote metaobjects
>     and link them into the right places, but then flush those links when the
>     compilation is over.  
> 
> This depends on whether you think the environment actually contains the
> table that relates names to objects, or just contains a boolean flag
> that tells functions such as FIND-CLASS which of two tables to look in.
> Under the latter model, nothing about the environment prevents the
> COMPILE-FILE table from being reset at any time.  This is one reason
> why I think the second model is right.

But if you reset the table, then a FIND-CLASS on that environment will no
longer be meaningful, which has the same effect as being outside the valid
extent of the environment.