Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

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

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

One other thing I would like clarified.  It makes sense to be able to
have more than one distinct remote environment around at any given
time; for example, if COMPILE-FILE is called recursively it ought to
create a new remote environment for each file.  Does it make any sense
to have more than one distinct local environment around, or is there
only one?  I can imagine that a Lisp running on a non-shared-memory
parallel machine might want to maintain separate local environments on
each processor, for instance.  Would doing so automatically make that
Lisp not be Common Lisp? 

-Sandra
-------