On Thu, Dec 9, 2010 at 3:50 PM, <ro...@racket-lang.org> wrote: > > 18dacad Robby Findler <ro...@racket-lang.org> 2010-12-09 10:20 > : > | a first attempt at a rewording of the blame error messages to admit the > possibility that the contract was wrong and also to claim that fixing the > blamed module or the contract is all that is required > |
For anyone following at home, the change turns this message /Users/clklein/tmp/contract-violator.rkt:9.17: (file /Users/clklein/tmp/contract-violator.rkt) broke the contract (-> any/c any/c any/c) on #:equiv argument of test-->; expected a procedure that accepts 2 mandatory arguments without any keywords, given: 1 into this one /Users/clklein/tmp/contract-violator.rkt:9.17: found a contradiction between the contract (-> any/c any/c any/c) on #:equiv argument of test--> for (file /Users/clklein/tmp/contract-violator.rkt) and its implementation; expected a procedure that accepts 2 mandatory arguments without any keywords, given: 1; to fix adjust either the contract or the implementation of (file /Users/clklein/tmp/contract-violator.rkt) Personally, I don't see the phrase "m broke the contract c" as denying, or even suggesting, that c is wrong. But I know that contracts are specifications and that specifications have bugs too, so I'm not the reader you're worried about. If we're seeing people misinterpret the message, I wonder if it would be better to tack something like "The problem may be with m or with c" onto the end of the old message. That said, I'm a little worried about giving so much debugging advice in the message. Consider this program. #lang racket/load (module m racket (define non-neg-num/c (and/c number? (not/c negative?))) (define abs-codom/c ;non-neg-num/c number?) (define abs values) (provide/contract [abs (-> number? abs-codom/c)] [sqrt (-> non-neg-num/c non-neg-num/c)])) (module n racket (require 'm) (sqrt (abs -7))) (require 'n) The resulting message says to fix either the contract on sqrt or the module n, but the problem is really in the definition of abs (and its contract). Yes, n has a problem too (it should not use sqrt without protecting itself with a stronger contract on abs), but someone who would misread the original error message would probably not recognize this problem. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev