On Fri, Dec 10, 2010 at 8:26 AM, Casey Klein <clkl...@eecs.northwestern.edu> wrote: > On Fri, Dec 10, 2010 at 7:00 AM, Eli Barzilay <e...@barzilay.org> wrote: >> >> As for a suggestion, I don't have anything concrete (and I don't have >> nearly enough contract experience to say something concrete) -- but in >> general I prefer to see those important bits first, and the vague >> human text later. >> > > This organization was my goal in suggesting that we tack an > explanation onto the old message. I was imagining something like this: > > /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. Possible fixes include changing (file > /Users/clklein/tmp/contract-violator.rkt) and changing the contract.
I like the idea of better error messages, and in that spirit, I suggest: newlines. For example: /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. Possible fixes include changing (file /Users/clklein/tmp/contract-violator.rkt) and changing the contract. For an effective use of text formatting in error messages, the GHC type error messages are good examples. -- sam th sa...@ccs.neu.edu _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev