[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Sun, 12 Feb 89 19:20:29 MST
- Cc: Sandra J Loosemore <email@example.com>, David N Gray <Gray@DSG.csc.ti.com>, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 10 Feb 89 17:13 EST
Having seen the new proposal for EVAL-WHEN, I still don't have any idea
why the extent of macro environment objects depends on it. Can you
explain the connection?
Also, I don't think anybody is arguing for requiring environments to
have indefinite extent on the grounds that CLOS requires it. (The
argument is that it's generally useful and for general symmetry with
every other kind of Lisp data object having indefinite extent.) Just
the opposite -- David Gray's question was whether that requirement
would complicate the implementation of CLOS.
At the January meeting, Gregor made a verbal suggestion that perhaps
implementations ought to be allowed to support only dynamic extent, but
that we should add a function to make a copy of the environment object
which would have indefinite extent. If the problem is indeed that
certain things must be "unlinked" at the end of compilation, it
doesn't seem like this would solve the problem.