Skip to content
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

Feature Request: Pure interface for Gen #65

Open
konn opened this issue Aug 13, 2023 · 1 comment
Open

Feature Request: Pure interface for Gen #65

konn opened this issue Aug 13, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@konn
Copy link

konn commented Aug 13, 2023

Hi,

First of all, thank you for your great library and great expositions! This library is really cool indeed.

Feature Request: Pure interface for Gen

Currently, there is an impure interface to sample a value from Gen:

sample :: Gen a -> IO a

It would also be nice to have a pure analogue for this. The most straightforward one could be:

sampleFrom :: SMGen -> Gen a -> a

Unfortunately, this leaks the implementation detail. So perhaps it could be something like this:

data GenSource -- opaque (could be just a newtype wrapper around SMGen or SampleTree)
mkGenSource :: Word64 -> GenSource
sampleFrom :: GenSource -> Gen a -> a

Background

Recently, I use falsify to test the validity of transformations on propositional formulae.
The test worked well, and I eventually have several valid implementations with different performance characteristics. So I decided to take some benchmarks on them.

To do that, I have to generate some random formula of a specific size. Surely, we can do this with sample :: Gen a -> IO a. One downside of sample function is the lack of reproducibility - as sample initialises SMGen from the air on every invocation, we don't have any access to the seed it used.
Once we have sampled some formulae from Gen, we must save them on a disk. This becomes tedious when one needs multiple formulae. If we can sample a value from specified seed, then we can just hard-code the seed instead.

@edsko
Copy link
Collaborator

edsko commented Aug 14, 2023

Yes, that absolutely seems reasonable. Perhaps the library should offer a public API that can be used to define both the tasty and the ghci interfaces, and then that would then also give applications such as the one you describe what they need. I will probably not have time for this in the next few weeks though :/

@edsko edsko added the enhancement New feature or request label Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants