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
