Richard M Kreuter wrote:
> Liam Healy writes:
>> I don't know what you mean by "executed the relevant defmethods
>> before compiling the function call";
> I mean evaluating the relevant DEFMETHOD forms (as opposed to merely
> compiling them).
> The problem is a tension between wanting a compiler that can catch a
> common sort of mistake (typos in keyword argument names) and supporting
> a minor CLOS feature that makes reasoning about calls to generic
> functions hard (that methods can add keywords to a GF's calling
> interface). When I made the change last year, the users I consulted,
> who wanted some error detection, said that the compromise of updating
> the compiler's idea of the function's type as a side effect of method
> addition and removal seemed reasonable. And, as I mentioned, including
> the keyword arguments or &ALLOW-OTHER-KEYS in the DEFGENERIC's lambda
> list or in an explicit FTYPE declaration should (i.e., is intended to)
> satisfy the compiler's ideas about what constitutes a valid call to a
> generic function.
But doesn't &allow-other-keys throw away a lot of baby with the
bathwater? I.e., it muffles warnings in this situation, yes, but at the
cost of really throwing away all checking, and leaving the programmer
with nothing but his or her own care to avoid errors.
It may be that the CL spec just doesn't offer us a happy exit from this