Each existing properties can come with a batch of generic test to test some usual corner cases, to check that property holds. It would indeed be easier if some elements of the domain/range could be given (or an automatic generator). Random testing would be good, but I don't think it's necessary to impose this constraint to have good assurance that the operator is well defined.
Do you know why C++ has stopped pursuing this idea by any chance? On Sun, May 5, 2013 at 6:58 PM, Matthias Felleisen <matth...@ccs.neu.edu>wrote: > > On May 5, 2013, at 12:51 PM, Laurent wrote: > > On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen > <matth...@ccs.neu.edu>wrote: > >> >> C++ has tried this tack for some time. > > > Sounds like it has failed then. > > >> I can see doing for built-ins but how would you go about >> programmer-created operations? Trust the programmer? -- Matthias >> > > Well, I guess some checks can be added, but I don't see the difference > between attaching bad properties to a newly created operator and defining a > buggy procedure. > > > > I think it is one thing to say > > (define (fahrenheit->celsius f) 32) > > and another to attach "associative" to the floating-point + operator. > Since we all write examples first and translate then into test suites > before we code, finding a bug in fahrenheit->celsius is straightforward and > supported by our support mechanisms. If you don't trust your tests, attach > contracts to your procedures because they generalize tests in a natural > way. Finding bugs in false claims about functions is much less supported at > the moment. Perhaps random testing or model checking or something like that > may help along here. > > -- Matthias > > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
