-
Notifications
You must be signed in to change notification settings - Fork 21
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
Provide comibnators using uniform #22
Comments
Yeah, I have been wanting to move over to Uniform. I wouldn't be opposed to a PR support both the Uniform/Random variants for a short term (using CPP).
Note that you can currently use |
In this case it's really about the type level machinery I'm interested in, not so much the non-deterministic behavior (in fact it was already set).
I was thinking of keeping the old functions in place but adding other ones that use Uniform instead. Allowing users to choose whatever type class they like. After all, random isn't deprecated or anything |
@jappeace I looked into this today and it seems I need to only introduce two more function: https://hackage.haskell.org/package/fakedata-0.7.0/docs/Faker-Combinators.html I was surprised that only two functions requires the |
Adding |
I tried implementing this and got stuck because of dependency issues as it seems the ecosystem hasn't yet adopted to random-1.2.0 yet. I think I would wait till this issue get's closed: commercialhaskell/stackage#5474 |
It exists for backward compatibility, and using uniform we get a much more useful api.
For example, it can automatically figure out uniform tuples and it expects the underlying monad to carry around the seed.
I ran into this issue today. Now I just worked around it by running the random function by hand twice and passing the stdgen by hand around.
Checkout the docs, they recommend using uniform as well:
https://hackage.haskell.org/package/random-1.2.0/docs/System-Random.html#t:Random
The text was updated successfully, but these errors were encountered: