Re: Issue SYNTACTIC-ENVIRONMENT-ACCESS

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Wed 22 Feb 89 16:27:51-PST
> From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
> 
> Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):
> 
>  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.

One other thing that ought to be clarified here: CLtL p. 145-146 says
that the &environment argument received by a macro does not have to be
the complete lexical environment.  We should be explicit that we are
changing this and requiring &environment arguments to contain all of
the information that the accessors this proposal defines can get at.

I am not so sure that extending this proposal to EVALHOOK environments
is such a good thing.  For one thing, implementations that do some
kind of preprocessing or partial compilation may not have anything
like the kind of information this proposal requires available.
Another problem is that I am not convinced that this information is
really all that useful to implementations that want to use EVALHOOK.
(For instance, I've recently been working on some debugging tools
where I've wanted to do things like draw pictures of the various
lexical contours as nested boxes, showing the values of all the local
variables in those contours.  This proposal wouldn't give me the kind
of information I need to do that.)


> 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 flamed about this at length when the last version of the proposal
came out: there are more situations than these in which code may be
processed!!!  Moon suggested that we distinguish only between local
and remote environments, and rename this function ENVIRONMENT-REMOTE-P.  
I think that would make a lot more sense.


> Some function names may refer to both a global macro and a global special
> form.  In such a case, the macro takes precedence, and :MACRO is returned as
> the first value.

I'm not so sure that this is the right choice.  Any code walker ought
to have special knowledge about things that the standard explicitly
says are special forms, even if they happen to be implemented as
macros.  I think it would be more useful to return :SPECIAL-FORM in
such cases.  I agree that :MACRO should be returned for things that
are documented as being macros in the standard but that also have a
special form implementation.


> ENVIRONMENT-TYPE variable env                  [Function]

Can we please call this function ENVIRONMENT-VARIABLE-TYPE again?
To me, ENVIRONMENT-TYPE implies that it returns information about the
kind of environment, not the type of variables in the environment.

> ENVIRONMENT-FTYPE function env                 [Function]

Perhaps ENVIRONMENT-FUNCTION-TYPE would be a better name?


> AUGMENT-ENVIRONMENT env &KEY lexical
>                              special
>  			       symbol-macro
>                              function
>                              macro
>                              type
>                              ftype		[Function]

Two problems here:

- shouldn't there be a way to create a null environment object?

- how does one specify the remoteness (or target) of the resulting 
  environment?

Is there any reason why the newly created environment object should
-not- have indefinite extent?  One of the alternatives suggested for
issue MACRO-ENVIRONMENT-EXTENT was to allow &environment objects to
have only dynamic extent within the macro function, but to provide
some kind function to make copies that do have indefinite extent.
Would calling AUGMENT-ENVIRONMENT with no keyword arguments do that?

Also, I think it needs to be made more clear that the original
environment is not destructively modified by this function.


> 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.  The association between names and property lists uses
> EQUAL to match names.  The search of the property list uses EQ to match
> properties.  If the property is not found in the environment's local property
> list, the global property list of the name is searched.  If the property is
> not found on the global property list, then default is returned.
>
> Note that the global property list of a name is not necessarily the
> symbol-plist of the name. 

This doesn't make much sense to me -- you seem to be contradicting
yourself about whether this attaches "global" or "local" properties to
names.  Perhaps you mean that if the environment is a "remote"
environment, than the properties are local to that environment, but if
it's a non-remote environment, then the properties are global?

I am uncomfortable about the idea of allowing environment objects to
be destructively modified.  Suppose I have an environment E1 and I
pass it to an argument to AUGMENT-ENVIRONMENT to get environment E2.
If I then modify the property list of E1, are the changes also
reflected in E2?

I think this particular item needs more rationale to support it.  I
gather that this is supposed to be the internal mechanism by which
CLOS hangs information about the class structure off the environment?
Why does this need to be generalized -- what is wrong with having
FIND-CLASS be the primitive accessor for this kind of information?

-Sandra
-------