Issue MACRO-ENVIRONMENT-EXTENT

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

Your recent statement that you are convinced that CLOS made a mistake with
regard to environments has made me reconsider the problem, and I think I may be
convincable.  I'm going to throw some thoughts your way to see if maybe we can
reach some definite, defendable, conclusions on the subject.

Right now, our implementation provides some functions for manipulating remote
environments without specifying the environment as an argument.  These
functions work by referencing a special variable bound by the compiler.
Currently the only places it is legit to put calls to them is in the compiler
itself or in (eval-when (compile) ...) forms.  It wouldn't be hard to arrange
for a compiler-like user program to be able to use these.

It is because these functions usually seem to be adequate for the job that I
think you might be right.  The places where they currently don't work seem to
be precisely those places where somebody has said that a function (like
find-class) takes an environment argument just to distinguish between remote
and local environments.

Suppose we were to say that T is a special indicator for the remote null
lexical environment, just as NIL is a special indicator for the local null
lexical environment.  Then find-class could be defined as

  (defun find-class (name &optional (errorp t) env)
    (cond ((and (environment-remote-p env)
		<< look it up in the remote environment, in some special >>))
	  (<< look it up in the local environment >>)
	  (errorp (error ...))
	  (t nil)))

and your suggestion of using T as the argument to find-class works, and all the
places which might want to call find-class can either pass in an environment
argument if they've got one handy (rather than forcing them to call
environment-remote-p and passing the result) and it is legit to do so within
the constraints of the extent of the environment, or they can call
environment-remote-p and pass the result if they can't use the environment
because of the extent problem, or they can use T or NIL if they happen to know
which they want.

Saying that T is a null environment looks a little funny, but I thing something
like this would simplify some of SYNTACTIC-ENVIRONMENT-ACCESS and sort of
normalize everything.

To make this all fly we would have to say some things about when it is legit to
use T as an environment, but I don't think this is hard.  Admitedly, people can
get strange bugs if they use it wrongly, but many of the same kinds of problems
can occur with passing around environments that are real data structures.

The one thing I'm concerned about is the use of a special to hold the
environment.  I think its ok, as long as there is some specified way to bind it
and everybody who wants to do compile-file-like things uses that mechanism.
Some sort of with- construct, and don't even bother to document what the
special variable is, seems to me to be the right way to go.  The only case I
can think of where this might be a problem is if somebody were trying to
distribute the work of their 'compilation' over multiple processes/processors,
and I think any system that would support doing such a thing is likely to have
some mechanism for doing what's needed, like being able to have process trees,
with children inheriting bindings from parents.

Note that this does throw away the possibility of operating on multiple
distinct remote environements at the same time.  I mentioned this in a message
a while back to the small group discussing remote environment issues.  Is that
so bad?  Maybe we'll just have to say "Tough. You can't do it."

Note that I read your message after sending out version 3 of
syntactic-environment-access, which includes some stuff that goes off in a
different direction from what I think you are suggesting.  If we can agree to
something like what I'm describing here, that proposal will have to be yanked
around to a somewhat different path.

kab
-------