issue CLOS-MACRO-COMPILATION, version 1

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

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

Forum:		Compiler
Issue:		CLOS-MACRO-COMPILATION
References:	CLOS chapters 1 & 2 (88-002R)
		CLOS chapter 3 (89-003)
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION
Edit History:   V1, 10 Mar 1989, Sandra Loosemore
Status:		**DRAFT**


Problem Description:

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.


Proposal CLOS-MACRO-COMPILATION: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.

  DEFCLASS:
  
  * 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
    DEFCLASS.
  
  * The class name can be used as a specializer in a subsequent 
    DEFMETHOD.
  
  DEFGENERIC:
  
  * The generic function can be referenced in a subsequent DEFMETHOD.  

  * The generic function is not callable at compile-time.
  
  DEFMETHOD:
  
  * 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 
    load time.]
  
  DEFINE-METHOD-COMBINATION:
  
  * 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.

 Rationale:

  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.

Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:

 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.

 Rationale:

  Being able to instantiate a class at compile-time is somewhat more 
  convenient for users.


Current Practice:

  The items listed under DEFCLASS in proposal MINIMAL are fairly standard
  programming style.

  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:

  Unknown.

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

Benefits:

  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.

Discussion:

  Loosemore says:

    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.

-------