re: Issue SYNTACTIC-ENVIRONMENT-ACCESS

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

Just for the record, here are the relevant bits of back mail I have
dealing with why we should consider only ENVIRONMENT-REMOTE-P instead
of specific targets for the environment.  It seemed like we had pretty
much reached consensus on this before and I think it we have better things
to do with our time than hash this all out again. 


 From: sandra%defun@cs (Sandra J Loosemore)
Date: Mon, 3 Oct 88 10:56:21 MDT

> Date: Sun, 2 Oct 88 11:30:37 pdt
> From: Eric Benson <eb@lucid.com>
> 
>  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 really dislike this part of the proposal.  I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed.  The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file.  I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.


Date: Mon, 3 Oct 88 22:51 EDT
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    >  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 really dislike this part of the proposal.  I hate to have to keep
    repeating myself, but there are other situations besides the three
    listed here in which code may be processed.  The example I've cited
    before is a filter that reads in code from a file, performs some
    preprocessing to decorate the code with lots of type declarations, and
    writes it out to another file.  I contend that anything that needs to
    know whether the code is being processed by the interpreter or
    compiler ought to be a special form (this includes EVAL-WHEN and
    whatever we decide to do about LOAD-TIME-EVAL) and should be left
    strictly alone by code walkers.

I think we have some confusion here between interpreter versus compiler
on the one hand, and operating in the local Lisp world versus outputting
to a file to be loaded later on the other hand.  I feel that it is
completely inappropriate to add something that distinguishes between
the compiler and the interpreter.  I'd like to see that part of the
proposal dropped.

The important distinction is between what I will call local environments
and remote environments.  A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
evaluated in a local environment affects the current Lisp world, but in
a remote environment it does not affect the current Lisp world, however
its effects still need to be remembered in a model of the Lisp world
that will be created later.  Both COMPILE-FILE and your example program
annotating program work with remote environments.  I defy you to come up
with an example where the local/remote environment distinction doesn't
make sense and a third type is needed.  Thus I think ENVIRONMENT-TARGET
would better be named ENVIRONMENT-REMOTE-P.

[...]

Again the compiler/interpreter distinction is a red herring and CLOS has
no reason to care about that distinction.  The important distinction
is local/remote.  CLOS needs to know whether a DEFCLASS form changes the
behavior of objects of that class in the current world, or only affects
a future ("remote") world.  Whether this information is "inside" the
environment or "associated with" the environment is a red herring too,
I think; it's a matter of implementation, but has no effect on the
functional interface that the user sees.  I think it's better only to
standardize the one thing that has to be standardized, the local/remote
distinction, and leave the rest (the actual name<->object mapping) to
the discretion of individual implementations.  That way we'll get this
business over with quicker.

 From: sandra%defun@cs (Sandra J Loosemore)
Date: Mon, 3 Oct 88 22:00:24 MDT

> Date: Mon, 3 Oct 88 22:51 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> The important distinction is between what I will call local environments
> and remote environments.  A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
> evaluated in a local environment affects the current Lisp world, but in
> a remote environment it does not affect the current Lisp world, however
> its effects still need to be remembered in a model of the Lisp world
> that will be created later.  Both COMPILE-FILE and your example program
> annotating program work with remote environments.  I defy you to come up
> with an example where the local/remote environment distinction doesn't
> make sense and a third type is needed.  Thus I think ENVIRONMENT-TARGET
> would better be named ENVIRONMENT-REMOTE-P.

That's a very nice way to put it.  Rather than trying to introduce
*more* kinds of environments, I would actually go in the other
direction and say that code walkers shouldn't even need to know the
distinction between local and remote environments.  An implementation
ought to be free to use different representations for the two, but as
long as the accessors return the correct information, is there any
reason why you would need to know where it came from?

> Again the compiler/interpreter distinction is a red herring and CLOS has
> no reason to care about that distinction.  The important distinction
> is local/remote.  CLOS needs to know whether a DEFCLASS form changes the
> behavior of objects of that class in the current world, or only affects
> a future ("remote") world.

That's pretty much what I was trying to say: CLOS doesn't really need
to know whether the information is needed by the compiler or
interpreter or something else, as long as it finds the right
information. 

If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment.  The existing proposal assumes that everything the
compiler doesn't create must be an EVAL (that is, local) environment. 


Date: Wed, 5 Oct 88  18:58:37 CDT
 From: David N Gray <Gray@DSG.csc.ti.com>

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

-------