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 <matth...@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 <ro...@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 <sa...@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 > > <ro...@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 > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
