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

Reply via email to