Integrated shrinking

[1Jajen1]

Benefits:

• A user would not have to write a shrinking function for most if not all data-types
• Shrinking automatically follows invariants by construction. This reduces duplication in logic that checks/maintains those when manually shrinking
• Allows to get rid of Arbitrary which is in itself not a big problem, but jut a hassle to implement, carry around and lookup.
• Since shrinking is coupled to generators and changes to gen also change shrinking, which is a good thing if for example range is changed you'd not want shrunk results to be outside of that range

This comes with a few drawbacks:

• When two generators are combined monadically they are shrunk one after the other and if the first one fails to shrink it will not be shrunk again. This can be overcome with using Applicative combinators wherever possible. Yet another way to overcome this is to simply add back a shrinker. While certainly not great, it gives the same level of control as type based shrinking (Or at least I think it does)
• Generating functions relies on Coarbitrary and Function and some unsafe methods. I do not want to loose generating functions so there must be a way. I'd be fine keeping the typeclasses for the two, also the unsafe methods, but this needs to be done in a way that still allows integrated shrinking to work

My take on this atm is: Convenience over the best possible shrinking (which can still be recovered by extra work if needed). I'll start playing around with integrated shrinking once the internal rewrite is done.

This is a very good resource on the differences between the two and their drawbacks: http://www.well-typed.com/blog/2019/05/integrated-shrinking/#fnref10