Re: issue CLOS-MACRO-COMPILATION, version 1

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

> Date: Fri, 10 Mar 89  18:06:53 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> >     [This also seems to imply that tests for existence of the generic 
> >     function, lambda-list congruence, etc. must not happen until 
> >     load time.]
> 
> No, an implementation should be permitted to check for lambda-list
> congruence between methods defined in the same file; this doesn't
> require any reference to the resident generic function definition.  If
> the file doesn't include a DEFGENERIC, then the first DEFMETHOD defines
> the compile-time generic function attributes, and subsequent methods can
> be checked against that.

The description of DEFMETHOD in CLOS chapter 2 talks about calling
FBOUNDP and signalling an error if the function is not a generic
function, or if it is a generic function but the lambda list of the
method is not congruent.  Clearly this shouldn't happen at
compile-time.  I agree that the behavior you suggest makes more sense. 

> 
> >   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.
> 
> But if methods are not installed at compile time and generic functions
> are not callable at compile time, then I don't think there is any
> situation in which the method combination body could be executed at
> compile-time.

This is something I couldn't quite figure out from reading chapters 1
& 2.  At what time does the method combination become "integrated"
into the DEFGENERIC?  Does the process of expanding the DEFGENERIC
macro capture the method combination definition, in the same way that
expanding a SETF macro captures the setf method?  Or does this happen
when you actually execute the DEFGENERIC macro?

-Sandra
-------