[racket-dev] Racket2 suggestion: Attaching properties to operators

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 <matthias at 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 <matthias at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130505/c4062db8/attachment.html>