Issue SYNTACTIC-ENVIRONMENT-ACCESS

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

> Date: Thu, 23 Feb 89  20:21:36 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> > 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?

Yeah.  I keep forgetting to be more explicit about NIL.

> 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]

I tried to avoid making major syntactic changes from version 1, so as to
proceed in smaller steps in case of a misstep.  Also, I had been thinking about
these functions as being sort of accessors on environments, apparently mentally
reversing the arguments to these functions (ie. (fn-name env ...)).  Now that
its been pointed out to me, I think I prefer your suggested syntax.

> I agree with Sandra's comments that ENVIRONMENT-REMOTE-P makes more sense,

Having now seen the arguments for this, I'm mostly inclined to agree.  I do
have one reservation though, because I would like to have the ability to
differentiate between interpreted and compiled situations.  If neither this nor
EVAL-WHEN gives me that capability, then I have a problem with the situation.
More on this in a seperate message.

> and that AUGMENT-ENVIRONMENT needs an argument to specify whether a remote
> environment is being created. 

No, the intent is that AUGMENT-ENVIRONMENT returns an environment whose
remoteness is the same as the environment supplied as an argument.  There is
nothing in this proposal which specifies how to create a new remote environment
out of nothingness.  I want that pushed over to WITH-COMPILATION-UNIT, so that
we can talk about the extent of an environment in terms of the extent of the
creating form.

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

This was a slip on my part.  Yes.

> 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. 

I agree there is an argument that type declarations ought to be optional,
especially since the implementation is free to otherwise completely ignore
them.  Since most uses of the type information are going to require using
SUBTYPEP, which could return `unknown', anybody using this information is
probably going to have to include reasonable default handling as well.

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

Syntactic analysis means passing it to almost anything which takes an
environment argument, with the exception of EVALHOOK.

> 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. 

There is no intent to require property lists in the implementation, merely that
there exists this function which behaves as if there were property lists
underlying it.  For example, the mechanism for handling local environments
might do case analysis on the name and property and invoke some specialized
code to deal with a particular case.  For example, if the property is the
symbol MACRO-FUNCTION, and the name is a symbol, it might manipulate the
function cell of the symbol, while if name is a SETF function name it might go
to a special hash-table created for that purpose.

kab
*****
to sandra
-------