[racket-dev] TR & check-equal?

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Wed May 29 11:19:57 EDT 2013

Yes: my message is about strange error messages that cause newbies to just
conclude that testing TR programs doesn't work. While I can certainly fault
someone for coming to this conclusion (and I did) I think only half of the
problem is on their side.

If they had gotten this message, they might have said "equal? isn't what I
want here" and then maybe made some progress.

But I do agree with you and if it is hard to get to even this state, then
it probably isn't worth pursuing.

Robby


On Wed, May 29, 2013 at 10:11 AM, Matthias Felleisen
<matthias at ccs.neu.edu>wrote:

>
> If TR lived up exactly to the R level of semantics, to wit:
>
> > Welcome to DrRacket, version 5.3.4.10--2013-05-29(05524114/d) [3m].
> > Language: racket.
> > > (struct s ())
> > > (require rackunit)
> > > (check-equal? (s) (s))
> > --------------------
> > FAILURE
> > actual:     #<s>
> > expected:   #<s>
> > name:       check-equal?
> > location:   (unsaved-editor324 5 2 126 22)
> > expression: (check-equal? (s) (s))
> >
> > . . Check failure
> > --------------------
>
>
> would you really write a different message to dev? Opaque structures pose
> a problem for testing and that problem exists at both levels.
>
> -- Matthias
>
>
>
>
>
>
> On May 29, 2013, at 8:02 AM, Robby Findler <robby at eecs.northwestern.edu>
> wrote:
>
> > Well, given that replacing check-equal? with equal? (on the typed side)
> works, then it seems to me that one solution would be to move more of
> rackunit into TR, or to refactor rackunit to be more friendly to TR. (And
> if someone is going to work on this, then it would also be great if the
> error messages from failed test cases were made a bit more legible.)
> >
> > Robby
> >
> >
> > On Wed, May 29, 2013 at 6:53 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> wrote:
> > That is indeed the correct fix.  I'm not entirely sure how to improve
> > the error message, since the problem in your original code is real.
> > There's no way the generated contract can tell at runtime that the
> > values passed to `check-equal?` aren't higher-order, so it has to
> > conservatively reject the call.  Suggestions are certainly welcome.
> >
> > Sam
> >
> > On Wed, May 29, 2013 at 7:46 AM, Robby Findler
> > <robby at eecs.northwestern.edu> wrote:
> > > I'm not sure if this should be considered a bug or a feature request
> (or
> > > something else, but hopefully one of those two!) so I thought I'd ask
> here
> > > before sending in a PR. This program:
> > >
> > >   #lang typed/racket
> > >   (require typed/rackunit)
> > >   (struct: s ([a : Integer]))
> > >   (check-equal? (s 1) (s 2))
> > >
> > > produces the output:
> > >
> > > check-equal?: broke its contract
> > >   Attempted to use a higher-order value passed as `Any` in untyped
> code:
> > > #<s>
> > >   in: the 1st argument of
> > >       (recursive-contract
> > >        (->* (Any Any) (String) any/c)
> > >        #:impersonator)
> > >   contract from: (interface for check-equal?)
> > >   blaming: (interface for check-equal?)
> > >   at: <collects>/typed/rackunit/main.rkt:20.2
> > >
> > > which is a bit confusing. (As someone who's been around Racket long
> enough,
> > > I guessed that sticking #:transparent into the struct declaration
> would be a
> > > thing to try, but newcomers seem unlikely to find that workaround.)
> > >
> > > Robby
> > >
> > >
> > > _________________________
> > >   Racket Developers list:
> > >   http://lists.racket-lang.org/dev
> > >
> >
> > _________________________
> >  Racket Developers list:
> >  http://lists.racket-lang.org/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130529/d1ecd5c4/attachment-0001.html>

Posted on the dev mailing list.