[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 13 Mar 89 12:13:13 CST
- Cc: David N Gray <Gray@DSG.csc.ti.com>, firstname.lastname@example.org, "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>, "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: Msg of Sat, 11 Mar 89 16:29:06 MST from email@example.com (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> 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
That would be fine.
> I think this would fit in with issue SYNTACTIC-ENVIRONMENT-ACCESS, but
> I'm still confused about why you would still need COPY-ENVIRONMENT.
COPY-ENVIRONMENT would only be needed if there are implementations using
stack list environments that disappear as soon as the macro expander
returns. Kent, does Symbolics need this?
> 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?
I want to be able to do something like this:
(defun VARIABLE-KIND (variable &optional environment)
(if (compiler:compilation-environment-p environment)
(case (compiler:var-type (compiler:lookup-var variable compiler:vars))
;; else handle interpreter environment
where the attributes of the variable are actually found in special
variable compiler:vars instead of in the environment object. This would
permit implementing proposal SYNTACTIC-ENVIRONMENT-ACCESS without
needing to redesign the compiler's data structures.