compile-time side effects

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

I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros.  Unfortunately, I'm not at all sure what the side effects
should be.  Can somebody who really groks CLOS please help me out? 

DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations).  Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file.  Does this mean that
it must also construct a real class object at compile time?  Are the
reader, writer, and accessor functions defined at compile time?

DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time.  Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time?  Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?

DEFINE-METHOD-COMBINATION:  My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?  

DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time.  Is the FBOUNDP test
supposed to happen at runtime or compiletime?  If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time?  Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time? 

-Sandra
-------