Hedgehog - Integrated shrinking, shrinks obey invariants by construction.

Hi everyone, I found the above interesting sentence in Hedgehog's [1] documentation. What does this mean? Is construction there somewhat tied to shrinking, perhaps something like going in the reverse direction? Thanks, Petr [1] https://github.com/hedgehogqa/haskell-hedgehog#features

Generators can be interpreted as the sets of values they generate, and "integrated shrinking" makes shrinking produce values that belong to the same set, by deriving it from the generator. In contrast, in QuickCheck, generators and shrinkers are separate, so if a property we want to test has some precondition, we need to remember to make both the generator and the shrinker satisfy these preconditions. Li-yao On 06/14/2018 04:24 PM, Petr Pudlák wrote:
Hi everyone,
I found the above interesting sentence in Hedgehog's [1] documentation. What does this mean? Is construction there somewhat tied to shrinking, perhaps something like going in the reverse direction?
Thanks, Petr
[1] https://github.com/hedgehogqa/haskell-hedgehog#features
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

That's interesting! Could you please elaborate how this is implemented?
Thanks, Petr
Dne čt 14. 6. 2018 23:12 uživatel Li-yao Xia
Generators can be interpreted as the sets of values they generate, and "integrated shrinking" makes shrinking produce values that belong to the same set, by deriving it from the generator. In contrast, in QuickCheck, generators and shrinkers are separate, so if a property we want to test has some precondition, we need to remember to make both the generator and the shrinker satisfy these preconditions.
Li-yao
On 06/14/2018 04:24 PM, Petr Pudlák wrote:
Hi everyone,
I found the above interesting sentence in Hedgehog's [1] documentation. What does this mean? Is construction there somewhat tied to shrinking, perhaps something like going in the reverse direction?
Thanks, Petr
[1] https://github.com/hedgehogqa/haskell-hedgehog#features
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On 06/15/2018 07:31 AM, Petr Pudlák wrote:
That's interesting! Could you please elaborate how this is implemented?
Sure. Whereas QuickCheck declares "shrink" as a function, in Hedgehog generating and shrinking are performed simultaneously. Instead of generating a single value, we can generate a rose tree of them, where the main output is at the root, and the other nodes carry shrunk versions of it, with the smallest ones at the leaves. It works quite nicely and efficiently in Haskell thanks to laziness, so that the shrinking part only happens as needed. The main drawback might be that there is some duplicated work during shrinking ((>>=) applies its second argument to different arguments), but it is quite minor since shrinking is only needed in exceptional cases, and it usually terminates in few steps. Li-yao

"LX" == Li-yao Xia
writes:
LX> The main drawback might be that there is some duplicated work during LX> shrinking ((>>=) applies its second argument to different arguments), but LX> it is quite minor since shrinking is only needed in exceptional cases, and LX> it usually terminates in few steps. I've recently switched from QuickCheck to Hedgehog for my property testing, and having found that the implied shrinking is indeed a very nice behavior. Shrinking is one of those principled ideas that rarely happens in execution, so any methodology for automating it is appreciated. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
participants (3)
-
John Wiegley
-
Li-yao Xia
-
Petr Pudlák