Unfortunately, it is impossible to distinguish the two kinds of contracts. Even if we introduced two different linguistic mechanisms, we would simply confuse programmers more.
Let's try this experiment for a while and see what happens. On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > I think the vast majority of contract errors that Racket programmers > see will be from contracts that the particular programmer didn't > write. For example: standard library contracts, or contracts from > packages they install, or contracts generated by Typed Racket, or > other such. > > For example, here's a simple contract error: > > -> (require scribble/core) > -> (part-parts 7) > ; part-parts: contract violation > ; expected: part? > ; given: 7 > ; in: the 1st argument of > ; (-> part? (listof part?)) > ; contract from: > ; <pkgs>/scribble-lib/scribble/core.rkt > ; blaming: top-level > ; (assuming the contract is correct) > ; at: <pkgs>/scribble-lib/scribble/core.rkt:164.2 > > What does the "assuming the contract is correct" mean to the > programmer here? They can't change the contract, and it's not obvious > in what sense the contract being incorrect would change anything. > > In general, I think that your new message makes a lot of sense if > programmers mostly experience contracts as strong invariants > protecting complex components specified publicly -- the sort of thing > you've talked about as a "marketplace of components". But I don't > think that's how Racket programmers typically experience contracts -- > instead, they're more like the example above: simple specifications > protecting small functions implemented privately and used as > error-checking. > > Sam > > On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> I do not buy this argument: the user didn't write the compiler but they >> wrote the contract. >> >> Robby >> >> >> On Monday, July 14, 2014, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: >>> >>> This seems like a situation where the new error message is potentially >>> more confusing, even though it's technically more correct. There are >>> lots of other caveats we could add ("assuming there isn't a compiler >>> bug", etc) but I think adding them would make Racket harder to use. >>> >>> Sam >>> >>> On Mon, Jul 14, 2014 at 9:11 AM, <ro...@racket-lang.org> wrote: >>>> robby has updated `master' from 737330deb6 to 1dda800ca2. >>>> http://git.racket-lang.org/plt/737330deb6..1dda800ca2 >>>> >>>> =====[ One Commit ]===================================================== >>>> Directory summary: >>>> 100.0% racket/collects/racket/contract/private/ >>>> >>>> ~~~~~~~~~~ >>>> >>>> 1dda800 Robby Findler <ro...@racket-lang.org> 2014-07-14 08:09 >>>> : >>>> | add contract-correct caveat to contract violation error messages >>>> : >>>> M racket/collects/racket/contract/private/blame.rkt | 1 + >>>> >>>> =====[ Overall Diff ]=================================================== >>>> >>>> racket/collects/racket/contract/private/blame.rkt >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> --- OLD/racket/collects/racket/contract/private/blame.rkt >>>> +++ NEW/racket/collects/racket/contract/private/blame.rkt >>>> @@ -320,6 +320,7 @@ >>>> from-line >>>> on-line >>>> blaming-line >>>> + " (assuming the contract is correct)" >>>> at-line)) >>>> >>>> ;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?) > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev