Re: issue CLOS-MACRO-COMPILATION, version 1

[David N Gray <Gray@DSG.csc.ti.com>]

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

Right, unless it is viewed as doing the FBOUNDP in the compile-time
environment without inheritance from the resident environment.

> > 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?

This is only in chapter 3, and not very clear there even.  My
understanding of it is that the method combination body would be invoked
 from COMPUTE-EFFECTIVE-METHOD, which, depending on the implementation,
could be invoked as soon as a call to ADD-METHOD, or as late as a call
to the generic function which actually needs that particular
combination.  Since it operates on a list of applicable methods, it
couldn't be invoked from DEFGENERIC.  The generic function object would
just have a pointer to the method combination object for future use.