Suggestion to add FunDeps MonadRandom g m | m -> g - This is not a useful setup since it will require a generator to depend on a specific monad, which we are trying to avoid.

I don't quite understand this. It says that given m we can determine g. But for any g we can have arbitrarily many monads

I don't quite understand this. It says that given m we can determine g. But for any g we can have arbitrarily many monads

@Shimuuar That is precisely why this suggestion cannot work. But considering that it has been suggested by at least 3 people that I know of, there is some confusion. Probably because people only think with transformers in their mind. Therefore I decided to solve the problem of confusion with an approach of renaming. Maybe StatefulGen, will make people think about generator first and a monad second

Posting here a plan that I already shared privately for recovering freeze/thaw functionality:

Just as before, but with a bit of renaming

class StatefulGen (g s) m => SeededGen g s m | g -> s, m -> s where
  type Seed g = (r :: *) | r -> s
  saveGen :: g s -> m (Seed g)
  restoreGen :: Seed g -> m (g s)

This would not only recover all of our functionality back, but also make it possible to create an instance for: https://www.stackage.org/haddock/lts-8.24/mersenne-random-1.0.0.1/System-Random-Mersenne.html#t:MTGen
Which I totally forgot about. It doesn't have a frozen state, so we can have StatefulGen instance, but not SeededGen

Other benefits of splitting this freezing/thawing functionality into a separate class is:

• It will be visible at the type level when a function relies on a potentially expensive operation of thaw+freeze
• type signatures of majority of our functions become slightly simpler, since they loose that s, (eg. uniformM :: StatefulGen g m => g -> m a, vs uniformM :: MonadRandom g s m => g s -> m a)

@lehins Now I'm even more confused. Why are saying that it's impossible? As I see both designs are pretty much equivalent. In one design dispatch is done over g type. In another it's done over monad m. Right now It writing PR with alternative design and translation is straightforwad and almost mechanical. In former design there're StateGen/StateGenM to link RandomGen & MonadRandom. In latter there's functionally identical RandT newtype

Just to add to #144 (review) - my working assumption for the review was that we'd find some other way to add freeze and thaw back, e.g. following the approach in #144 (comment). I suggest holding back until @Shimuuar has had a chance to present what I understand to be an alternative approach.

Why are saying that it's impossible? As I see both designs are pretty much equivalent.

@Shimuuar I am not saying it is impossible, I am saying it is strictly worse! And they are far from equivalent. In MonadRandom g m | m -> g you are forced to define a new monad transformer be it RandT or what have you, which comes with a lot of baggage, like creating instances and forcing users to deal with stacks of transformers. I am really against such an approach. I do not want to see lift . lift . lift .... just in order to use different RNGs in a single function.

By definition of g m | m -> g makes it impossible for m to be ST or IO, therefore you can't possibly call these designs equivalent.

@Shimuuar Given IO it should not be determined what type of generator is being used. That will mean the library cannot be agnostic with respect to PRNG and so if you want to try out different implementations you need to constantly change the monad you are using. I think it sounds like a bad design that should be avoided if you want to be agnostic.

Now I understand. So main arguments against m -> g approach are: 1) it makes it necessary to define specific newtypes for generator types. That's fair criticism while I think that with appearance of DerivingVia it's much less of a problem. 2) It couldn't work with IO/ST which is again fair.

On other hand what are problems of StatefulGen approach. 1) One have to thread g manually which is annoying. 2) type inference for RandomGen based instances is rather poor. For example type for uniform StateGenM couldn't be inferred. I'm not sure how much it's of a problem. No one used proposed API.

@lehins By "equivalent" I meant that everything written in one style could be straightforwardly translated into other. But some things could be easier in one style of another.

On other hand what are problems of StatefulGen approach.

1. One have to thread g manually which is annoying.

This is orthogonal to the current design because it can be easily solved by MonadReader. In some future release we can maybe add extra functions that avoid the manual passing of generator around, but I don't think it is worth to do it right now.

2. type inference for RandomGen based instances is rather poor. For example type for uniform StateGenM couldn't be inferred. I'm not sure how much it's of a problem. No one used proposed API.

It is best to use StateGenM with helper functions, such as runStateGen, etc. then type inference is not a problem. In fact StateGenM acts as a simple proxy, because otherwise type of pure gen would be ambiguous. Moreover, once I bring SeededGen back from the #144 (comment) it will be even less of a problem, because StateGenM constructor never needs to used by the user.

Posting it here new addition, which I think is really cool:

Here is the new freeze/thaw interface I came up with. It is even better than before. @Shimuuar suggested at some point before possibility of flipping frozen and mutable around, but before it would have looked really ugly (every stateful gen would have had a signature Mutable f m), but with the split into two classes it looks great. I think overall it removes all the warts that I didn't like that where in MonadRandom g s m class, namely redundant state token for pure parameter and unnecessary state token in the class head itself:

class StatefulGen (MutableGen f m) m => FrozenGen f m where
  type MutableGen f m = (g :: Type) | g -> f
  freezeGen :: MutableGen f m -> m f
  thawGen :: f -> m (MutableGen f m)

mwc-random is a pleasure to look at

instance PrimMonad m => FrozenGen MWC.Seed m where
  type MutableGen MWC.Seed m = MWC.Gen (PrimState m)
  thawGen = MWC.restore
  freezeGen = MWC.save

and pure gen adapters are just as beautiful 🙂

instance (RandomGen g, MonadIO m) => FrozenGen (IOGen g) m where
  type MutableGen (IOGen g) m = IOGenM g
  freezeGen = fmap IOGen . liftIO . readIORef . unIOGenM
  thawGen (IOGen g) = newIOGenM g

runGenM is just as wonderful

runGenM :: FrozenGen f m => f -> (MutableGen f m -> m a) -> m (a, f)

It is best to use StateGenM with helper functions, such as runStateGen

That's why said that I'm unsure whether it'll be problem in practice. However one shouldn't underestimate ability of library user of using in weird and unanticipated ways. However only way to find out is to release library

Also new version of FrozenGen resolves last problem. Now it's possible to write instance for StateGen and instance is present. I think at this point there's no alternate design that is clearly better. So it's better release this design and try it out in practice