You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all shrinking is done naively & directly on the choice sequence (see here). This is neither customizable, nor anywhere close to optimal (and not at all how Hypothesis proper does it).
The plan for this is the following:
Implement region tracking on a per-Possibility basis, preferrably automatically tracking which Possibility we're currently in
Implement region shrinking, giving information about what the region represents
Expose an interface for hooking into shrinking on a per-Possibility basis
My current idea is to follow what Hypothesis does about half way, informing how the regions are tracked. A custom shrinker would be given access to the part of the choice sequence it's responsible for, having it return a newly modified choice sequence as a replacement. It may be necessary to rework the interface surrounding Possibility a bit to do so - e.g. proptest returns a ValueTree when producing elements, similar to what PropCheck/Hedgehog do (except smarter when it comes to laziness of shrunk values).
The text was updated successfully, but these errors were encountered:
Idea: Require Possibility to implement the 2-arg produce, but only make it legal to call the 1-arg produce, even from within an existing produce. The reasoning is that the 1-arg produce can then attach every Possibility to a Shrinker, which can be potentially a custom one for that Possibility type. If the 2-arg produce is called directly, no shrinkers/metadata will be attached/managed.
Currently, all shrinking is done naively & directly on the choice sequence (see here). This is neither customizable, nor anywhere close to optimal (and not at all how Hypothesis proper does it).
The plan for this is the following:
Possibility
basis, preferrably automatically tracking whichPossibility
we're currently inPossibility
basisMy current idea is to follow what Hypothesis does about half way, informing how the regions are tracked. A custom shrinker would be given access to the part of the choice sequence it's responsible for, having it return a newly modified choice sequence as a replacement. It may be necessary to rework the interface surrounding
Possibility
a bit to do so - e.g. proptest returns aValueTree
when producing elements, similar to what PropCheck/Hedgehog do (except smarter when it comes to laziness of shrunk values).The text was updated successfully, but these errors were encountered: