Proposal: Move 'split' into a separate class in System.Random

Thomas DuBuisson thomas.dubuisson at gmail.com
Sat Oct 9 11:02:14 EDT 2010


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
<jmaessen at alum.mit.edu> wrote:
>> 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
>


More information about the Libraries mailing list