In the Haskell library, properties are merely functions (usually). Their types indicate how they're wired up to arbitraries, and that wiring happens "magically" through typeclasses. Racket however has neither typeclasses nor the ability to easily examine type-level information (I think that's possible through macros but it gets complicated fast). And many Racketeers use no types at all (gasp!).
In light of this, I propose separating properties (judgements about values) from specifications (claims that a property holds for certain sets of values). The Quickcheck user first creates a property. Any predicate can be a property, for example "even?". Then the user creates a specification claiming that the property holds for a set of inputs:
By separating the two, properties can have richer semantics. For instance properties can return additional information like classifications and measurements of their inputs, and this can be expressed as a plain function rather than using the monadic approach of Haskell's QuickCheck. This also allows specifications to include more information, for instance a set of inputs to try every time (known bugs or corner cases) before trying arbitrary inputs (something that the Python version of quickcheck, Hypothesis, does).
@ifigueroap, @dented42, I've got some exploratory work in this direction and it seems promising. What do you think?
In the Haskell library, properties are merely functions (usually). Their types indicate how they're wired up to arbitraries, and that wiring happens "magically" through typeclasses. Racket however has neither typeclasses nor the ability to easily examine type-level information (I think that's possible through macros but it gets complicated fast). And many Racketeers use no types at all (gasp!).
In light of this, I propose separating properties (judgements about values) from specifications (claims that a property holds for certain sets of values). The Quickcheck user first creates a property. Any predicate can be a property, for example "even?". Then the user creates a specification claiming that the property holds for a set of inputs:
By separating the two, properties can have richer semantics. For instance properties can return additional information like classifications and measurements of their inputs, and this can be expressed as a plain function rather than using the monadic approach of Haskell's QuickCheck. This also allows specifications to include more information, for instance a set of inputs to try every time (known bugs or corner cases) before trying arbitrary inputs (something that the Python version of quickcheck, Hypothesis, does).
@ifigueroap, @dented42, I've got some exploratory work in this direction and it seems promising. What do you think?