[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
user interface macros
- To: email@example.com
- Subject: user interface macros
- From: David Gray <firstname.lastname@example.org>
- Date: Thu, 3 May 90 11:47:44 PDT
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Cyphers@STONY-BROOK.SCRC.Symbolics.COM, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Dussud@lucid.com, email@example.com, firstname.lastname@example.org, email@example.com, mop.pa@Xerox.COM
- Cc: firstname.lastname@example.org
- In-reply-to: Gregor J. Kiczales's message of Wed, 2 May 90 16:13 PDT <19900502231329.0.GREGOR@SPIFF.parc.xerox.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
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.