CLOS defining macros & compilation

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

This is an attempt to summarize the problems that have been raised so
far about the compilation semantics of the various CLOS defining
macros.

  The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
  DEFGENERIC macros in the meta-object protocol document specify that
  subforms be evaluated at compile-time in the lexical environment in
  which the defining macro appears, which is not fully defined until
  run-time.  The obvious solution to this problem is to say that the
  compile-time evaluation happens only when the defining macro call
  appears at top-level, the same as for all the other defining macros.
  However, some people have questioned whether compile-time evaluation
  is even necessary at all, especially in the case of DEFMETHOD and
  DEFGENERIC.
  
  The meta-object protocol does not say anything about whether
  DEFINE-METHOD-COMBINATION has compile-time side-effects.
  
  The CLOS spec assumes that compile-time class and method definitions
  are made available through a remote lexical environment object.  The
  full implications of this are not well-understood and we have little
  or no experience with actual implementation.
  
  The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
  DEFGENERIC macros in the meta-object protocol document assume that
  lexical environment objects received with &ENVIRONMENT have indefinite
  extent.  Some people have argued that it ought to be legal for
  environment objects to have only dynamic extent (issue
  MACRO-ENVIRONMENT-EXTENT).  There have also been concerns expressed
  about how COMPILE-FILE should "clean up" the class structure to remove
  definitions made during compilation.

Now, as to what I suggest we do about all of this.

I believe that there are enough serious problems with the compilation
semantics presented in the meta-object protocol document distributed
before the January meeting that it would be a mistake to try to
standardize that behavior.  It does not appear that any alternate
proposal is forthcoming from the CLOS committee in time for us to make
the March 15th deadline (that's less than 3 weeks away, folks).

To me it appears that the only practical solution for the near term is
a minimal proposal that leaves many aspects of the behavior explicitly
vague.  (Basically, that DEFCLASS makes the class name recognizable as
a valid type name in subsequent declarations, but leaving unspecified
whether or not real class, method, etc. objects are fully defined at
compile-time.)  It may well happen that at some point the MOP
compilation semantics will be fixed and the behavior can be specified
more tightly, but I don't see any sign of that happening within the
next couple of weeks.

I think that one of the things we must leave explicitly vague is the
use of remote lexical environment objects to contain compile-time
definitions.  Proposal COMPILE-TIME-HANDLING-OF-TOP-LEVEL-FORMS allows
implementations considerable freedom in how other kinds of definitions
(DEFMACRO, DEFSTRUCT, etc.) are made available to the compiler; it
says only that such definitions *are* made available.  Why not do the
same thing for the CLOS defining macros?  I certainly don't want to
discourage people from continuing to pursue the issues involved, but
the work seems too experimental yet at the stage to fall into the
domain of a standards committee.

-Sandra
-------