Re: issue MACRO-ENVIRONMENT-EXTENT, version 1

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 10 Feb 89 13:55:36 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I am still trying to understand all of the implications of what CLOS
    wants to do with macro expansion environments.  

Resolving that is dependent on resolving EVAL-WHEN.  You either already
have the Symbolics proposal for EVAL-WHEN, or will have it soon (I'm not
sure if Kent sent it yet).  I think only Sandra will see this draft, the
mailing lists should see it shortly afterwards.

						    To me, it seems like this
    whole business would be difficult to retro-fit to existing implementations,
    regardless of what we decide to do about the extent of macro environments.

My opinion is that anything in CLOS that seems to depend on indefinite
extent for macro environments is broken and needs to be fixed.  It's not
broken because of the environment extent, but for other reasons.

Thus I believe in dynamic extent for environments.

    > Date: Fri, 13 Jan 89  17:33:28 CST
    > From: David N Gray <Gray@DSG.csc.ti.com>
    > That's fine for macro definitions, but this will not work for environments
    > containing class definitions.  The compiler needs to be able to know when
    > those compile-time class definitions are no longer needed so that they can
    > be unlinked from the class data structures.

    My current mental picture of how this is supposed to work is that
    compile-time environment objects are supposed to contain a pointer to
    a database of all the class definitions.  

"pointer" is a key word that usually means you are thinking at too low
a level of abstraction.  Also that mental picture may or may not be wrong,
depending on how we resolve how CLOS metaobjects work at compile time,
which depends on resolving EVAL-WHEN first.

					      I don't see why the compiler
    would need to unlink anything; when there are no longer any pointers
    to the database, it would get "unlinked" automatically during garbage
    collection, just like any other object, right?

When Gray said "unlink" he was referring to the links between subclasses
and superclasses, not the links between names and objects.