Generate shrink implementations in quickCheckTool

[adinapoli]

Fixes #84 by implementing shrink for our existing Arbitrary instances via genericShrink.

As that requires the datatypes deriving a Generic instance, I have also added a genericsTool to smooth things out.

I have transplanted the dataTypeableTool that I used in Atlas to generate Data instances, for syb & co.

[adamgundry]

Apologies for not realising before now, but I don't think we necessarily need to add tools that merely derive standard classes, because datatypesTool' already makes it possible to change the derived classes alongside the datatype definition. Maybe we need to make that API more convenient/discoverable, though.

I'm in two minds about use the use of genericShrink. I can see it is easy to add, but the additional compile-time cost seems like it could well be significant for a large schema, and it shouldn't be that hard (famous last words) to generate shrinker implementations using TH.

[adinapoli]

Apologies for not realising before now, but I don't think we necessarily need to add tools that merely derive standard classes, because datatypesTool' already makes it possible to change the derived classes alongside the datatype definition. Maybe we need to make that API more convenient/discoverable, though.

@adamgundry yes, I'm aware of datatypesTool', but alas I can't remember now which specific problem (or self-inflicted problem) I stumbled upon when using it directly in Atlas, apologies for not coming up with a coherent narrative.

I'm in two minds about use the use of genericShrink. I can see it is easy to add, but the additional compile-time cost seems like it could well be significant for a large schema, and it shouldn't be that hard (famous last words) to generate shrinker implementations using TH.

I can try looking into that, or bail out if that proves to be too tricky; I understand that the compile-time cost for Generic on a big schema might be significant.

[adinapoli]

@adamgundry I'm completely fried after a day intermittently staring at TH splices,but I think we are almost there, but I have ran out of steam on shrinkRecord, which works but it's not correct. I have mimicked the behaviour of what the generic instance would do, and the latter would generate something in this flavour:

    -- For records, using the same principle behind 'genericShrink', we need
    -- to generate a list of lists, each sublist being the shrinking of a single
    -- individual field, and finally mconcat everything together.
    -- Example:
    -- shrink = \(Foo a b c) ->
    --  (Foo <$> shrink a <*> pure b   <*> pure c) ++
    --  (Foo <$> pure   a <*> shrink b <*> pure c) ++
    --  (Foo <$> pure   a <*> pure b   <*> shrink c)

However, my TH-fu failed me and at the moment I'm generating something like:

Foo <$> shrink a <*> shrink b <*> shrink c

which wouldn't shrink properly, and I know for a fact as in the past (scrapped in the last commit) I have generated a QuickCheck property to check in lockstep the genericShrink behaviour. I think it would be relatively easy for you to fix my code.

Then, we can try in Atlas, maybe generating (locall) a silly test with a degenerate FK, and see if things shrinks fine (or, failing that, I can use my WIP traversal branch to generate a huge payload there).

[adinapoli]

@adamgundry This is now ready to go -- I have cherry-picked your commit and implemented shrinkEnum. Tested on Atlas that this is shrinking things as it should!

[adamgundry]

We're getting there! Thanks @adinapoli.