Re: issue MACRO-ENVIRONMENT-EXTENT, version 2

[David N Gray <Gray@DSG.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
>   MACROEXPAND-1.

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.