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

From: Sam Tobin-Hochstadt (samth at cs.indiana.edu)
Date: Mon Jul 14 11:04:43 EDT 2014

On Mon, Jul 14, 2014 at 10:57 AM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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.

I certainly agree with that.

I just don't think the additional line in that error message is very
helpful, and it's already a long and scary error message.

Sam

> Let's try this experiment for a while and see what happens.
>
>
>
>
> On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt <samth at 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
>> <robby at 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 <samth at 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,  <robby at 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 <robby at 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
>

Posted on the dev mailing list.