[plt-scheme] When is flat-named-contract necessary/useful?

When -> gets a predicate as an argument (as opposed to something that
is already a contract, it calls flat-named-contract, supplying the
name of the procedure if the procedure has a name.

Does that answer the question?

Robby

On 7/10/08, Richard Cobbe <cobbe at ccs.neu.edu> wrote:
> I have a question about the pragmatics of the contract system in PLT 4.
>
> I've never been completely sure exactly when `flat-named-contract' is
> helpful.  Section 7.3.1 of the PLT Scheme Guide suggests that it helps make
> contract violation errors more readable, and certainly the second version
> of the `myaccount' module from that section does indeed produce a clearer
> error message when the contract on `deposit' is violated.
>
> But it doesn't look like `flat-named-contract' is necessary to get the
> clearer error message, as the following version of `myaccount' seems to
> work just as well:
>
>     #lang scheme
>
>     (define (amount? x) (and (number? x) (integer? x) (>= x 0)))
>
>     (provide/contract
>       [deposit (amount? . -> . any)])
>
>     (define this 0)
>     (define (deposit a) (set! this (+ a this)))
>
> Now, the error message that you get on evaluating `(deposit -10)' in a
> different module says "expected <amount?>" rather than "expected
> <amount>".  Is that the only difference?
>
> Are there other situations in which flat-named-contract gets you more than
> an error message without extra question marks?  Perhaps more important from
> a practical standpoint, are there situations where writing an arrow
> contract (or ->*, or ->d, etc.) and providing a predicate name as a
> subcontract will *not* result in error messages involving the predicate's
> name where using a contract defined with `flat-named-contract' would?
>
> These questions are related to the question of where the contract system
> gets the strings it uses for the expected value in error messages.  While
> I've never completely understood this either, we can leave the general
> explanation for another time.
>
> Thanks,
>
> Richard
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>