[ disclaimer: I am not a CMUCL developer. ] bob coyne <[EMAIL PROTECTED]> writes:
> The compiler sometimes prints out an annoying (and incorrect) > warning that callers of functions are passing the wrong number of > arguments. This happens when the called function has been redefined > to take a different number of arguments. The compiler lets the function > be redefined, but seems to hold on to the old information about how many > arguments it has and complains when any callers are subsequently recompiled > using the new (correct) number of arguments. I'm afraid most of what I can say is "yes, it does." There is a workaround that you can use, but unfortunately it's a bit of a sledgehammer: setting *DERIVE-FUNCTION-TYPES* to NIL will inhibit this warning, but it will also inhibit all other function type usage (so the compiler will be unable to deduce that (defun foo (x) (list x)) (defun bar (x) (1+ (foo x))) deserves a type mismatch warning). The default setting of *DERIVE-FUNCTION-TYPES* could probably be considered a bug, as it can lead to incorrect code being generated (as well as the warnings you've seen); on the other hand, for library compilation it leads to definite improvement in the quality of the compiler output. The good news is that (in SBCL) there is some work going into getting the best of both worlds; at present, the default setting of *DERIVE-FUNCTION-TYPES* is NIL in SBCL, so there is conforming behaviour by default; it is effectively set to T during file compilation for functions defined in the same file (see CLHS 3.2.2.3); and it is planned to allow the user to extend the range of this static unit by specifying an option to WITH-COMPILATION-UNIT. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
