[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue CLOS-MACRO-COMPILATION, version 1
> 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
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?