Issue MACRO-ENVIRONMENT-EXTENT

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

    Date: Sat 11 Mar 89 19:36:38-PST
    From: 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.

That's interesting, because that is exactly how I want to propose
things like the macroexpansion of defmethod should work.  The fact that
your implementation already works this way gives me more confidence
that I've made the right choice.

It's a little confusing, because this issue is being simultaneously discussed
on cl-compiler, common-lisp-object-system, and in private mail.  So if I say
something that seems totally off the wall, it might be that I'm assuming
you've seen something that was only sent to a different mailing list.

    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.  

What I'm going to propose is nil for the local null lexical environment,
compile-file for the special environment the compile-file function uses
as a model of the load-time null lexical environment, and also a macroexpansion
environment can be used provided you are within its dynamic extent.

As I think you and I have both mentioned at various times, this could be
extended to allow other kinds of environments, for instance one that allows
hypothetical class setups that aren't in force in the running world.  However
I don't want to propose that at this time; it can be an implementation extension
at present and maybe be standardized in some future standard.

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

Right.  environment-remote-p just has to accept the special symbol
compile-file as well as nil and macroexpansion environments.

    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.

What I plan to say is that compile-file as an environment is valid only
inside of an (eval-when (compile) ...).  I think that has just the right
behavior.  Note that compile must be the -only- situation specified.

    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.

I don't think we should specify that it's a special variable, only that
the functions such as find-class that deal with this thing know the
implementation-dependent way to find it.

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

Not entirely, see possible future proposal mentioned above.  What this really
does is to decouple the multiple remote environments idea from macroexpansion
environments.

    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.

Fortunately I haven't read that proposal yet.  I'll postpone reading it for
a few days.