All, I have updated the ticket/patch for this proposal [1]. It seems the community has agreed on
class RandomGen g where next :: g -> (Int, g) genRange :: g -> (Int,Int) genRange _ = (minBound, maxBound)
class (RandomGen g) => SplittableGen g where split :: g -> (g, g)
Notice SPJs good catch that SplittableGen should be constrained by
RandomGen is there (lacking discussion, but its hard to imagine
objection). I'm not sure what you, Jan, mean by removing Read and
Show constraints as I don't see any.
This will break the following hackage packages (thanks Bas):
mage, synthesizer, synthesizer-core, Haskelloids, ideas, local-search,
comonad-random, SpaceInvaders, rsagl, pkcs1, and hsgsom
All BCCed, of these only PKCS1 doesn't have a maintainer (a production
pkcs1 probably shouldn't be using split anyway).
Cheers,
Thomas
[1] http://hackage.haskell.org/trac/ghc/ticket/4314
On Thu, Oct 7, 2010 at 6:22 AM, Jan-Willem Maessen
The "Clean Break" would involve removing "split" from the RandomGen class and making a new class "SplittableGen" for this operation. The thought here is that not all generators can have a "split". Users of "split" would have to be explicit of their need for a Splittable generator.
The backward compatible change would keep "split" as a member of class "RandomGen" for which all instances would be constrained to also be instances of the "BasicRandomGen" class. BasicRandomGen would contain the traditional routines (next, genRange).
Removing the Read and Show constraints for splittable generators would be a Really Good Thing. It turns out implementing splittable generators efficiently (eg using Lennart's notion of splittable supplies) doesn't work in the presence of these constraints ---- or rather, one is faced with the choice of Read/Show yielding irreproducible results, or using an inefficient implementation of splittable supplies.
-Jan-Willem Maessen