Support for 'where' and 'counterexample' custom operations

[jacobstanley]

I also renamed the forAll builder to property as I think it's more correct. I think this name is better, not completely sure.

/cc @moodmosaic

[jacobstanley]

An example of the new operations in action:

Property.check <| property {
    let! x = Gen.int
    let! y = Gen.int
    where (x > 0 && y > 0)
    counterexample (sprintf "x * y = %d" <| x * y)
    return x * y > 0
}

[moodmosaic]

Report is there to support #25, right?

[jacobstanley]

It was just for failure messages, but it could be used to support #25 or any other types of things that we might want to track during a test run.

[moodmosaic]

How about marking Tuple as private? I don't think we care about exposing it to the users. 😉

Edit: I've now opened #30 for this.

[moodmosaic]

How about marking Tuple as private? I don't think we care about exposing it to the users. 😉

Edit: I've now opened #30 for this.

[jacobstanley]

Sounds good, will check out your PR

[moodmosaic]

If we mark Tuple as private, we may then [<AutoOpen>] it, and then we can get rid of that open directive.

Edit: I've now opened #30 for this.

[moodmosaic]

Same here.

Edit: I've now opened #30 for this.

[moodmosaic]

Yes! I find Property a better name, since we may not only support universal quantification in the future. 😉

One day, if we decide to support existentials (à la SmallCheck), we may still do that through some custom operation(s), and then we won't have to rename the builder itself – which may be a breaking change if we follow SemVer.

[moodmosaic]

It's also great that we don't have to use a lazy computation in this case! It seems to be just working out of the box.

Property.check <| property {
    let! n = Gen.int
    where (n <> 0)
    return 1 / n = 1 / n
}

//+++ OK, passed 100 tests.
//val it : bool = true

[moodmosaic]

👍 This is looking good!

• where and counterexample are impressive
• property looks good
• I've opened Mark Tuple as private and [<AutoOpen>], #30, based on the same (topic/zero-not-ideal) branch

[jacobstanley]

It's also great that we don't have to use a lazy computation in this case! It seems to be just working out of the box.

The key here is that PropertyBuilder implements Delay, so every line of the computation expression gets wrapped in Gen.delay and hence is lazy.