Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

[David N Gray <Gray@DSG.csc.ti.com>]

>     Also, it has
>  proven impossible to write a portable code walker in Common Lisp, due
>  to insufficient access to the information contained in environments
>  and the inability to augment environments with local function
>  definitions.

I can see how writing a code walker is easier if you can augment the
local macro information, but I don't see what all the rest of this stuff
is needed for.

> Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):
> 
>  The following functions provide information about syntactic
>  environment objects.  In all of the functions the argument named ENV
>  is a environment, of the sort received by the &ENVIRONMENT argument
>  to a macro.  In all cases it is an error to supply an argument which
>  is not a syntactic environment.

I would like to add that it is an error to use an environment object
outside of the dynamic extent of the macro expander invocation which
received it as an &ENVIRONMENT argument.  This proposal would be much
easier to implement if the implementation of these accessors were
permitted to, for example, recognize that the environment is a compilation
environment and then fetch the information from wherever the compiler
keeps it, than if the compiler's data structures had to be redesigned to
actually store all of the information in environment objects having
indefinite extent.

>  ENVIRONMENT-TARGET env				[Function]
> 
>   This function returns one of the three symbols EVAL, COMPILE or
>   COMPILE-FILE, depending on whether the environment is from the
>   interpreter, the in-core compiler, or the file compiler. 

I agree with Moon's comments that the real issue is local versus remote.

>  ENVIRONMENT-OPTIMIZE-LEVEL attribute env	[Function]
> 
>   ATTRIBUTE is one of the symbols SPEED, SPACE, SAFETY or
>   COMPILATION-SPEED.  This function returns an integer between 0 and
>   3, which reflects the current settings of the OPTIMIZE proclamation
>   or declaration.

I hope this doesn't require an evaluator to keep track of OPTIMIZE
declarations even though it has no use for them itself.

> Rationale:
> 
>  This proposal provides a portable interface to environment
>  information which must otherwise be obtained by
>  implementation-dependent means.  The ENSURE-GENERIC-FUNCTION and
>  FIND-CLASS functions of CLOS require the ENVIRONMENT-TARGET function. 

Yes, but I'm not sure that there is anything that can be portably done
with that information.  Just because the implementation needs to do
something is not sufficient justification for making it available to
users.  In this case, I suspect that CLOS is going to need more than
ENVIRONMENT-TARGET to do everything it needs to do.

>    A
>  useful code walker requires the capability of adding local function
>  definitions to an environment.

So who requires the other capabilities?