[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue MACRO-ENVIRONMENT-EXTENT
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue MACRO-ENVIRONMENT-EXTENT
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 10 Mar 89 10:48:48 CST
- Cc: "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>, sandra%defun@CS.UTAH.EDU, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Msg of Thu, 9 Mar 89 13:59 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.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
> 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.