Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

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

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

Yes, in EB's proposal AUGMENT-ENVIRONMENT needs a :REMOTE argument
which defaults to the remoteness of the ENV argument and specifies
the remoteness of the returned 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.  

That's true, although I was refraining from proposing anything that
complicated.  If we get into that, then we also will have to make
environments extensible as I think I mentioned before.  But if we
confine ourselves to just putting in a way to tell whether this is a
remote environment or not, that will be enough to get CLOS off the
ground.

						    Does it make any sense
    to have more than one distinct local environment around, or is there
    only one?  

There is only one local global environment (gnashing of teeth in the
background over the terminology) in Common Lisp, but there can be more
than one in some dialects of Scheme (they're called "locales").
Multiple local global environments seem like a sound approach to solving
the same problems that packages were invented to solve.

On the terminology, this shows that "remote" is an okay word, but we
shouldn't use "local" as the antonym of "remote", since "local" is already
used as the antonym of "global".  How about "running"?

	       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.

No, I think you're confused here.  Environments have to do with the
mapping of names to objects (and to conceptual objects such as BLOCKs
and GO tags).  I don't think this has anything to do with addressing
memory, local or global, shared or non-shared.  I'm not sure what your
vision of a Lisp on a non-shared-memory parallel machine is, but I
suspect I would call it several independent Lisps talking to each other
through some communication medium.  In that sense there are multiple
local environments, since each Lisp has its own, but since the Lisps
don't share objects, this isn't an interesting distinction in the way
that the local/remote environment distinction in COMPILE-FILE is
interesting.