[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue CLOS-MACRO-COMPILATION, version 1
- To: email@example.com, firstname.lastname@example.org
- Subject: issue CLOS-MACRO-COMPILATION, version 1
- From: email@example.com (Sandra J Loosemore)
- Date: Fri, 10 Mar 89 13:56:05 MST
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 9 Mar 89 20:04 EST
Here is a first cut at getting something written down on this issue.
This is mostly extracted from David Gray's list of questions and
Moon's responses. To me it seems like the question where there is the
most disagreement is whether or not classes are required to be
instantiable at compile-time, so I have made two proposals. MINIMAL
leaves this unspecified, and NOT-SO-MINIMAL requires them to be
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Edit History: V1, 10 Mar 1989, Sandra Loosemore
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
is to say enough about the behavior of these macros in the standard so
that users can use them portably in compiled code, but to leave as
much of the behavior as possible unspecified to avoid placing undue
restrictions on the meta-object protocol.
There are two proposals, MINIMAL and NOT-SO-MINIMAL.
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
* The class name becomes a type specifier which may appear in
subsequent type declarations.
* The class name can be used to name a superclass in a subsequent
* The class name can be used as a specializer in a subsequent
* The generic function can be referenced in a subsequent DEFMETHOD.
* The generic function is not callable at compile-time.
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function.
[This also seems to imply that tests for existence of the generic
function, lambda-list congruence, etc. must not happen until
* The method combination can be used in a subsequent DEFGENERIC. If it
is referenced, the body of a long form of method combination must be
evaluable at compile-time.
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE. DEFGENERIC and DEFMETHOD are similar to DEFUN.
DEFINE-METHOD-COMBINATION is similar to DEFMACRO or DEFSETF.
This is the same as proposal MINIMAL, except under DEFCLASS add:
* The class may be instantiated at compile-time. Provided the
appropriate methods are also defined at compile-time, this implies:
- The class can be used as the :METACLASS option of a later DEFCLASS.
- It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.
Being able to instantiate a class at compile-time is somewhat more
convenient for users.
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Cost to users:
Unknown, but probably fairly small.
Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
any methods on the class which may be invoked at compile-time are
fully defined. This includes the INITIALIZE-INSTANCE and
SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I support proposal MINIMAL. I don't think
leaving the issue of whether or not classes can be instantiated at
compile-time unspecified places an undue burden on users, and it does
leave more freedom for the meta-object protocol to decide what the
right behavior really is.