user interface macros

[David Gray <gray@lucid.com>]

>     Defining NULL to be the predicate that tests whether an environment is the
>     run-time environment is not very abstract.  This could run into serious
>     problems with future extensions that unify this environment with the
>     &environment argument to macros or that implement more than just the run-time
>     and compilation environments.  On the one hand, NIL might not be the only
>     representation for the "ordinary" environment, and on the other hand, there
>     might be several distinct environments that all have the property of
>     containing classes that can be instantiated and methods that can be executed.

> I agree with all of these comments.  What if we just added an argument
> :COMPILE-ENVIRONMENT-P or something.  It would be true or false.  In
> cases where it is true it would mean the some other information, passed
> in implementation-specific keyword arguments had the real compile
> environment.

No, there should be just one environment argument.  Perhaps there should be
a function to test whether it is a compile-time environment (NULL is most
certainly not that function), but I would want to see the need for that
demonstrated first.  For the metaclass writer, the point is to be
consistent about passing the received environment on to FIND-CLASS,
MACROEXPAND, ENSURE-GENERIC-FUNCTION, etc.

I'm curious about Moon's phrase "future extensions that unify this
environment with the &environment argument to macros"; isn't that
unification already dictated by the current definition of FIND-CLASS?
I have implemented such unified environments on the Explorer and found that
it works very well, so this is not untested theory.