[plt-scheme] Questions about contracts

The contract system currently doesn't go inside and/c contracts when
printing out the specific part of the contract that failed. This is
both good and bad. In your case, you'd like a little less context, but
if you use contracts like 'integer?' it can sometimes be convenient to
have a little more context in the contract error message.

I've considered adding some kind of path information to the error
messages, but that adds additional complexity too, so haven't
attempted it yet.

Robby

On 4/15/07, Henk Boom <lunarc.lists at gmail.com> wrote:
> Hi, I'm trying to get a hang of the PLT contracts system. Coming from
> Eiffel, it feels a little awkward. =(
>
> I'm writing a simple object system, and I want to write a contract
> which prevents someone from adding the same signal to an object twice.
> Here's what I've written for this. It is a procedure which takes an
> object and a signal name as parameters and adds the signal to the
> object.
>
>   (define/contract add-signal
>     (->r ((object (and/c object?
>                          (not/c (has-signal/c name))))
>           (name symbol?))
>          void?)
>     (lambda (object name)
>       (set-object-signals!
>         object
>         (cons (make-signal name #f '())
>               (object-signals object)))))
>
> >From looking at the error message I'm starting to worry about what
> will happen with more complicated contracts:
>
> ---
> > (define foo (new-object))
> > (add-signal foo 'bar)
> > (add-signal foo 'bar)
> 50: 49 broke the contract
>   (->r ((object ...) (name ...)) ...)
> on add-signal; expected <(and/c object? (not/c has-signal))>, given:
> #<struct:object>
> [unknown source]: (temp9 object)
> [unknown source]: (val (temp9 object) (symbol?10 name))
> [unknown source]: (rng-id (val (temp9 object) (symbol?10 name)))
> [unknown source]: (let-values (((unused-id) (rng-id (val (temp9 ....)
> (....))))) (check-post-expr->pp/h val #t src-...
> ---
>
> It says that the contract on the first argument is broken, but it
> doesn't show which part of it. In this specific case it can sort of be
> inferred that it's the second component of the and/c which is failing,
> but what will I do when I have more elaborate contracts on the
> arguments?
>
>     Henk
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>