-
Notifications
You must be signed in to change notification settings - Fork 52
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
Deprecate RandomGenM
in favor of a more powerful FrozenGen
#149
Conversation
618b5e4
to
2fba77c
Compare
That's great! It provides direct correspondence between
|
Yes, that seems like a good feature to me. |
2fba77c
to
66f0f10
Compare
14ce716
to
c7eb9bd
Compare
* Addition of `modifyGen` totally removes the need for `RandomGenM`, because every frozen generator that is a wrapper around `RandomGen` also derives an instance for `RandomGen` * Add `splitMutableM` and `splitFrozenM` * Avoid redundant freeze in `withMutableGen_`
* Also add some laws for `FrozenGen` and `ThawedGen` This split of `FrozenGen` type class into two is needed because some mutable generators can't be cloned, becase the mutable state is stored in the monad they are running in, rather than in the mutable generator itself.
c7eb9bd
to
bc58313
Compare
@Shimuuar I've added |
Also fixup example with `FrozenGen` instance in haddock
modifyGen
totally removes the need forRandomGenM
, because every frozen generator that is anetwtype
wrapper aroundRandomGen
also derives an instance forRandomGen
splitMutableGen
andsplitGen
ThawedGen
and movethawGen
into that type class to combat current unlawfulFrozenGen
instance forStateGen