Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for custom shrinkers #3

Closed
Seelengrab opened this issue Feb 25, 2024 · 1 comment
Closed

Implement support for custom shrinkers #3

Seelengrab opened this issue Feb 25, 2024 · 1 comment
Labels
feature This is related to a new feature

Comments

@Seelengrab
Copy link
Owner

Seelengrab commented Feb 25, 2024

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).

@Seelengrab Seelengrab added the feature This is related to a new feature label Feb 25, 2024
@Seelengrab
Copy link
Owner Author

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.

Repository owner locked and limited conversation to collaborators Mar 4, 2024
@Seelengrab Seelengrab converted this issue into discussion #25 Mar 4, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
feature This is related to a new feature
Projects
None yet
Development

No branches or pull requests

1 participant