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

[Ian Lynagh]

On Wed, Sep 15, 2010 at 05:41:19PM +0100, Duncan Coutts wrote:
> On 15 September 2010 17:08, Thomas DuBuisson <thomas.dubuisson at gmail.com> wrote:
> > On Wed, Sep 15, 2010 at 7:57 AM, Ian Lynagh <igloo at earth.li> wrote:
> >> I approve, but what do you propose to do for haskell98:Random?
> >
> > Someone (me?) should make a matching proposal to Haskell' once we have
> > decided on a reasonable way forward.  WRT H98, modifying the Haskell98
> > library to have an upper bound on random 1.0.x would make sense.
> > Having two incompatible classes is rather inescapable when one is in a
> > standard and the other is its replacement.
> 
> Right, if we change the class then we do necessarily make it
> incompatible with H98, so H98 will have to have its own definition of
> Random that does not share type or class definitions with the random
> package.
> 
> I think at that point having the haskell98 package depend on the
> random package at all makes little sense. We would just take a copy of
> the old H98 code and put that in the H98 package.

Right. In particular, we need to be able to build haskell98 as part of
GHC, and it would be a lot simpler not to have 2 versions of the random
library around.

> > Henning said:
> >
> >> class StraightRandomGen g where
> >>  System.Random.next :: g -> (Int, g)
> >>  System.Random.genRange :: g -> (Int, Int)
> >>
> >> class StraightRandomGen g => RandomGen g where
> >
> > I favor a clean break with the past and small flurry of fixing
> > activity. The more concessions made in the base libraries the odder
> > all libraries will feel.
> 
> I agree. As much as possible I think we should deal with API changes
> using package versioning and not by making more convoluted names.

I agree too. The short-term pain for those who need to update their code
to include a Splittable constraint is preferable to the long-term pain
of living with the suboptimal names, IMO.


Thanks
Ian