re: Issue SYNTACTIC-ENVIRONMENT-ACCESS

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

> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Thu, 23 Feb 89 10:17:49 MST
>
> 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. 

Yes and no.  The &environment argument need not contain the additional stuff
that an EVALHOOK type environment needs to hold in order to look up the values
associated with bindings.  Since the functions in this proposal don't deal with
actial values, only the presence of bindings, the additional stuff isn't
required.  Also, I think I would be willing to allow support for the type and
ftype to effectively be optional.  This would allow an implementation to simply
ignore all type declarations.  Admittedly, this means that user code that wants
to see them won't either.

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

I think it is essential.  I also think the problem you are describing isn't
real.  The information must be present during the preprocessing or parital
compilation phase, and that's where macro expanders are going to get their
hands on an environment and do something with it.

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

Right, this proposal doesn't give you access to values in an EVALHOOK type
environment.  A portable interface to that kind of stuff might not be a bad
thing, but it is outside the scope of this proposal.  The filter I've been
using to decide what to include is whether the functionality is needed for your
hypothetical portable file-compiler example. 

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

Can you name some other situations?  Note that I regard :COMPILE-FILE as
refering not only to the implementation's compiler, but also to the
hypothetical portable file-compiler.  Perhaps I should make that more explicit.
This gets into the stuff I'm thinking about with regard to
WITH-COMPILATION-UNIT, which I haven't fully worked out and gotten it written
down yet.

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

I thought about this but decided to go with a uniform approach, since if a code
walker has special knowledge about the thing then it is only going to care if
there is a local definition which shadows the global definition.  Thus, if the
code walker has special knowledge about a name, it is going to treat the :MACRO
and :SPECIAL-FORM cases as synonymous, and meaning to go ahead and use its
special knowledge.

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

Maybe.  I definitely don't like the asymmetry of ENVIRONMENT-VARIABLE-TYPE and
ENVIRONMENT-FTYPE.  Mine are shorter, though I agree with you about the
potential confusion for ENVIRONMENT-TYPE.  Anybody else have an opinion?

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

NIL is the :EVAL targeted null environment.  Note that calling
AUGMENT-ENVIRONMENT with NIL as the environment and no keyword arguments can
legitimately return NIL.  It is my current intention that WITH-COMPILATION-UNIT
with appropriate options will get you a :COMPILE or :COMPILE-FILE null
environment. 

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

It is inherited from the env argument.

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

There in fact are problems with specifying indefinite extent for environments,
as I mentioned in a recent message on MACRO-ENVIRONMENT-EXTENT.
AUGMENT-ENVIRONMENT with no keyword arguments will get you a copy, but the copy
should have the same extent as the source, ie. the extent of the
WITH-COMPILATION-UNIT form that created their ultimate ancestor.

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

True, since at least one reader missed that point.

> > ENVIRONMENT-PROPERTY env name property &optional default
> > 
> >  ...
> 
> 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?

The wording needs to be worked on.  The intent is that if ENVIRONMENT-PROPERTY
is given a remote environment, it first examines the plist associated with that
environment.  Failing to find the property there, it then looks at the
non-remote environment.  The SETF method will modify the remote plist for a
remote environment, and the non-remote plist for a non-remote environment.

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

Yes.

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

In a sense it is true that this function is not needed if we specify FIND-CLASS
(and all the other accessors and update functions that make a remote/non-remote
distinction.  This function isn't just useful for CLOS.  See recent message
regarding SYNTACTIC-ENVIRONMENT-ACCESS).  However, without a function of this
sort it is much harder to write a PCL or similar portable program which needs
to record "global" information in the remote environment.  For example, we
wrote a user extensible external type system (for an RPC) that makes use of
built-in and user-defined encoder and decoder methods.  By straight-forward use
of our equivelent to ENVIRONMENT-PROPERTY, it was possible for the author of
this piece of code to make user-defined encoders and decoders accessable
downstream during a file compilation.  No other hooks into the compiler were
needed. 

An example of how it might be used is the following definition for something
like a Common Lisp MACRO-FUNCTION, where the expander is always kept on the
macro-expander property of the name.

(defun macro-function (name &optional env)
  (multiple-value-bind (kind localp)
		       (environment-function-kind name env)
    (when (eq kind :macro)
      (if localp
	  << do implementation-specific thing to find local macro >>
	  (environment-property env name 'macro-expander)))))

(defsetf macro-function (name &optional env) (expander)
  `(setf (environment-property ,env ,name 'macro-expander) ,expander))

kab
-------