[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Sat, 11 Mar 89 16:29:06 MST
- Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cl-compiler@sail.stanford.edu, "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>, "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>
- In-reply-to: David N Gray <Gray@DSG.csc.ti.com>, Sat, 11 Mar 89 15:08:25 CST
Hmmm. It sounds to me like you want the environment to have an extent
similar to the extent of the special bindings made by COMPILER-LET.
How about some wording like:
The extent of the environment objects passed to MACROEXPAND or
MACROEXPAND-1 by COMPILE-FILE, COMPILE, and EVAL is the dynamic extent
during which the macro and its expansion are processed. In
particular, the extent includes the expansion of any other macro calls
appearing lexically within the form returned from MACROEXPAND or
MACROEXPAND-1.
I think this would fit in with issue SYNTACTIC-ENVIRONMENT-ACCESS, but
I'm still confused about why you would still need COPY-ENVIRONMENT.
One other thing that's still not really clear to me is why you think
this is better than just saying they have (or can be copied to have)
indefinite extent. It would make the typed-variable example work but
not be of much use for macro-caching. Can you provide a more specific
rationale than just saying that it gives implementors more flexibility?
-Sandra
-------