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

From: Robby Findler (robby at cs.uchicago.edu)
Date: Thu Jul 10 18:58:17 EDT 2008

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?


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

Posted on the users mailing list.