From: Richard M K. <kr...@pr...> - 2009-02-02 00:27:43
|
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. -- Richard |
From: Richard M K. <kr...@pr...> - 2009-02-02 18:41:51
|
Robert Goldman writes: > Richard M Kreuter wrote: > > ... 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. I was only proposing &ALLOW-OTHER-KEYS as a workaround in case the compiler's warning was really intolerable. And anyway, do any practicing Lispers really suppose that absence of compiler warnings implies anything about an untested program...? :) > It may be that the CL spec just doesn't offer us a happy exit from this > situation. These are fairly minor details, but I suspect (without much evidence) that the ability to define generic functions implicitly with DEFMETHOD and to add keywords through individual methods is there to furnish a measure of source compatibility for Flavors or LOOPS programs. The (IMO) unfortunate consequence is that DEFGENERIC forms end up being optional and non-authoritative. As for SBCL's practice of issuing style-warnings about these sorts of things, I've seen these warnings expose bugs in some large systems (when the systems' build scripts didn't muffle the warnings, at least), so I'd be reluctant to do away with the warnings entirely. -- Richard |
From: Robert G. <rpg...@si...> - 2009-02-02 01:28:30
|
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 situation. best, r |