Re: Issue SYNTACTIC-ENVIRONMENT-ACCESS

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

> Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):

This generally looks like a reasonable proposal.  I think that this
could be added to my implementation fairly easily, assuming a suitable
limitation on environment extents.

>  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, or as the
>  environment argument for EVALHOOK.  In all cases it is an error to supply an
>  argument which is not a syntactic environment.

Don't you want to permit passing NIL to signify the global, null
lexical, environment?  In fact, since the usefulness of many of these
functions is not limited to local environments, instead of, for example,
  
 ENVIRONMENT-VARIABLE-KIND variable env         [Function]

it might be better to have:

 VARIABLE-KIND variable &optional env           [Function]

>  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.  If MACROEXPAND or MACROEXPAND-1
>   is called directly without supplying the environment argument, the
>   environment passed to any expander functions will have target :EVAL.

I agree with Sandra's comments that ENVIRONMENT-REMOTE-P makes more
sense, and that AUGMENT-ENVIRONMENT needs an argument to specify whether
a remote environment is being created.

>  ENVIRONMENT-TYPE variable env                  [Function]
> 
>   VARIABLE is a symbol.  This function returns the type specifier
>   associated with the variable named by the symbol in the environment.
>   If no explicit association exists, either by PROCLAIM or DECLARE, then
>   the result is the type specifier T.
...
>  ENVIRONMENT-FTYPE function env                 [Function]
> 
>   FUNCTION is a function name.  This function returns the functional type
>   specifier associated with the function in the environment, or NIL if there is
>   no functional type declaration or proclamation associated with the function.

Since the default type for variables is T, shouldn't the default for
functions be FUNCTION instead of NIL?

I would really like to see the proposal say that these two functions
will return information that the user put in the environment with
AUGMENT-ENVIRONMENT, but is not guaranteed to return anything other than
the default types when given an environment received from the evaluator
or compiler.  I don't want the interpreter to have to go to the trouble
of recording type declarations [that it doesn't use] just in case someone
might ask to see them later.

>   While an environment argument from EVALHOOK may be used as the environment
>   argument for this function, the reverse is not true.  It is an error to
>   attempt to use the result of AUGMENT-ENVIRONMENT as the environment argument
>   for EVALHOOK.  The environment returned by AUGMENT-ENVIRONMENT may only be
>   used for syntactic analysis.

Presumably it is also valid for MACROEXPAND, or is that included in what
you mean by "syntactic analysis"?

>  ENVIRONMENT-PROPERTY env name property &optional default
> 
>   This function and its SETF method allow the association of arbitrary 'global'
>   properties with names.  An environment can be thought of as having a local
>   property list associated with any name, and this function provides access to
>   that property list. 

It should be noted that only remote environments have property lists.
In my implementation, the real difference between local and remote
environments is whether storing into it affects the global environment
or is recorded locally.  In this proposal, (SETF (ENVIRONMENT-PROPERTY
...) ...) is the only way provided to store into an environment.