[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
- To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 13 Jan 89 17:33:28 CST
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Msg of Tue, 10 Jan 89 12:44:04 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Sender: GRAY@Kelvin.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. How about a compromise that
says that environments have a dynamic extent corresponding to the
invocation of COMPILE or COMPILE-FILE, rather than the individual macro
expansion? That would permit the compiler to clean up classes while still
letting your macro example work.
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.