purescript
Move Test.QuickCheck.Gen to seperate repo?
There are cases when you need to random values and the Gen monad will be handy in that case. It would be great if the Test.QuickCheck.Gen monad was published as purescript-lcg-gen (as Random.LCG.Gen) or something and reexported from Test.QuickCheck.Gen for compatibility reasons.
If this seams desirable please create a repo and will volunteer with PRs
I don't think this needs to have anything to do with quickcheck, it seems what you're asking about is just a stateful MonadGen instance that is not Gen?
The stateful MonadGen instance which i'm asking is already implemented here as Gen.
I think about renaming Test.QuickCheck.Gen to Random.LCG.Gen and move it in a repo purescript-lcg-gen
There's not really very much left in this library if you take Test.QuickCheck.Gen out. Is there a problem with depending on quickcheck?
It would still provide Arbitrary, Coarbitrary, the results and reporting stuff, etc.
I think if we were to make a separate library we'd want it to be GenT too, as being restricted to Gen might not be that useful in a non-test-context, since you can't do Effectful things without GenT.
Is there a problem with depending on quickcheck?
It's a discoverability problem.
If you just need to generate random data, but aren't using this data for testing purposes, then it's easy to assume that quickcheck is the wrong library for that job.
There's not really very much left in this library if you take Test.QuickCheck.Gen out.
I think small libraries are fine.
Is there any interest in doing this as part of the 0.14 library updates? Otherwise, we can reconsider it for 0.15.
I think small libraries are a pain, and rearranging things into separate libraries is a breaking change. I’m not super keen on this.
Actually, I suppose the original proposal isn’t necessarily breaking. It would be a bit awkward to indefinitely re-export this new Gen library from Test.QuickCheck.Gen though (for example, any breaking change in our new Gen library would have to imply a breaking change in quickcheck too), so I think we’d want to have a deprecation cycle and then remove it. But my main concern is really that we have too many small libraries at the centre of the ecosystem, and I think the discoverability issue could be mostly solved by writing a half decent blog post called “generating random data in PureScript with quickcheck” or something.
I think the discoverability issue could be mostly solved by writing a half decent blog post called “generating random data in PureScript with quickcheck” or something.
There's a lot of truth to this (or even updating this repo's docs / Readme) to state that, so people can find it via Google.
On another hand, if Gen was extracted from this repo, are there any Quickcheck implementations that depend on Gen specifically (you may have already stated this elsewhere)? In short, if one wanted to swap out a different generator, could they do so easily?
Actually, I suppose the original proposal isn’t necessarily breaking. It would be a bit awkward to indefinitely re-export this new Gen library from Test.QuickCheck.Gen though (for example, any breaking change in our new Gen library would have to imply a breaking change in quickcheck too), so I think we’d want to have a deprecation cycle and then remove it. But my main concern is really that we have too many small libraries at the centre of the ecosystem, and I think the discoverability issue could be mostly solved by writing a half decent blog post called “generating random data in PureScript with quickcheck” or something.
This still doesn't solve the problem of GenT, right?
As a way forward, here's what I'm proposing that doesn't cause any breaking changes. I can fork this repo, drop all the quickcheck stuff and explore the design space for just GenT. Then I can see in more detail what issues arise if quickcheck did depend on such a library and how that complicates its API surface.
If things works out, I can transfer the library to the purescript GH org and quickcheck can depend on it. If not, then at least my library enables people to generate things when purposes are not test-related.