[Openmcl-devel] check-defmethod-congruency error message

Gary Byers gb at clozure.com
Thu Jan 19 20:01:25 PST 2006



On Thu, 19 Jan 2006, John Wiseman wrote:

> Currently ccl::check-defmethod-congruency reports incongruent lambda
> lists like this:
>
> > Error in process listener(1): Incompatible lambda list in
> #<STANDARD-METHOD ADD-DOCUMENT (DOCUMENT-WRITER T)> for
> #<STANDARD-GENERIC-FUNCTION ADD-DOCUMENT #x8422EB6>
>
> How about changing it to report this instead:
>
> > Error in process listener(1): Method #<STANDARD-METHOD ADD-DOCUMENT
> (DOCUMENT-WRITER T)> has lambda list (SELF DOC &OPTIONAL ANALYZER)
> which is incompatible with generic function's lambda list, (SELF DOC)
>
> It just seems friendlier to show me the current GF lambda list than to
> make me hunt down the definition (that I have apparently forgotten or
> I might not have made the error in the first place).
>
>
> John
>
>
> (defun check-defmethod-congruency (gf method)
>   (unless (congruent-lambda-lists-p gf method)
>     (cerror (format nil
> 		    "Remove ~d method~:p from the generic-function and change its
> lambda list."
> 		    (length (%gf-methods gf)))
> 	    "Method ~S has lambda list ~S which is incompatible with generic
> function's lambda list, ~S"
> 	    method (method-lambda-list method) (generic-function-lambda-list
> gf))
>     (loop
>       (let ((methods (%gf-methods gf)))
>         (if methods
>           (remove-method gf (car methods))
>           (return))))
>     (%set-defgeneric-keys gf nil)
>     (inner-lfun-bits gf (%ilogior (%ilsl $lfbits-gfn-bit 1)
>                                   (%ilogand $lfbits-args-mask
>                                             (lfun-bits (%method-
> function method))))))
>   gf)
>
>

Agreed.

While playing around with this, I noticed that the code that prints (e.g.)
"Error in process ..." was originally not supposed to print the extra
"... in process ..." if the process in question was the initial listener,
but it wasn't testing for that correctly. I've gotten used enough to
seeing the longer error message prefix, so at first glance:

> Error: Lambda list of method #<STANDARD-METHOD STREAM-WRITE-STRING (T T)>, 
>        which is (STREAM STRING &OPTIONAL (START 0)),
>        is incompatible with that of the generic function STREAM-WRITE-STRING, 
>        which is (STREAM STRING &OPTIONAL START END). 
> While executing: CHECK-DEFMETHOD-CONGRUENCY

looks kind of wrong, but the shorter prefix makes it more likely that a long/
multiline error message will be readable.

Another approach would be to always print process context info, but to
print it along with other context info, e.g.:

> While executing: CHECK-DEFMETHOD-CONGRUENCY in process listener(1).

When dealing with the standard tty environment, the process context is
almost "dog bites man".  As everyone knows, it's the "man bites dog"
(error/warning occurred in some process other than the listener) case
that's generally more newsworthy.

Whether it's always printed or not, I think I'd rather see the process
info -not- causing long error messages to be even harder to read.  Does
anyone object to this change, or know offhand if it would break existing
code (SLIME, possibly ?)





More information about the Openmcl-devel mailing list