[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, sandra%defun@CS.UTAH.EDU
- Subject: Issue MACRO-ENVIRONMENT-EXTENT
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 9 Mar 89 13:59 EST
- Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: <12472024104.5.IIM@ECLA.USC.EDU>
Date: Sun 19 Feb 89 15:54:36-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
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
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.
As far as MACRO-ENVIRONMENT-EXTENT itself goes, I am convinced it should
be dynamic extent. I'm also convinced that the decision on this issue
does not affect CLOS.