[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue MACRO-ENVIRONMENT-EXTENT
> The extent of macro environment objects is related to EVAL-WHEN because macro
> expanders may wish to return forms which contain environments as quoted
> 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.