Re: issue MACRO-ENVIRONMENT-EXTENT, version 1

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Fri, 13 Jan 89  17:33:28 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> > Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
> > 
> > State that macro environment objects received with the &ENVIRONMENT
> > argument of a macro function have indefinite extent.
> 
> 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.
> 
> This issue has a strong relationship with issue
> SYNTACTIC-ENVIRONMENT-ACCESS since it proposes extending the use of
> environments in ways that would make anything other than
> MACRO-ENVIRONMENT-EXTENT:DYNAMIC difficult to retro-fit to existing
> implementations.

I am still trying to understand all of the implications of what CLOS
wants to do with macro expansion environments.  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 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.  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?

-Sandra
-------