[racket-dev] [plt] Push #21701: master branch updated

Thanks, Casey. Perhaps I should have announced our intentions in
changing this message but you've pretty much gotten it (implicitly
written below).

A little more detail: recently I got a complaint that the contract
system error messages were wrong, a complaint that I had now heard
many many times. The complaint was something of the form "The contract
system is blaming the wrong module; sure it can't know that because I
didn't write the right contract on there, but it really shouldn't be
blaming the wrong place". My response, of course, is that the contract
system is not really blaming the module so much as detecting that the
contract specs and the program are out of sync.

So, I made a first attempt to change the messages to more accurately
reflect what the contract system is actually saying. As you write
below, there is indeed a problem that the contract system has
accurately identified and, depending on what meaning you invest in the
word 'abs' and how you fix the problem that the contract system has
identified there may be another bug in this program elsewhere, too.

I think the messages are moving in a good direction, ie, a direction
that is better supported by what contracts actually do, but I agree
they can be better. I'm not sure how, tho. I do think that going back
to a message that leaves out the specs as a possible place that's
wrong isn't going to help.

Robby


On Fri, Dec 10, 2010 at 4:50 AM, Casey Klein
<clklein at eecs.northwestern.edu> wrote:
> On Thu, Dec 9, 2010 at 3:50 PM,  <robby at racket-lang.org> wrote:
>>
>> 18dacad Robby Findler <robby at 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.
>