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

[Thomas M. DuBuisson]

On Tue, 2010-09-14 at 16:44 -0700, Thomas DuBuisson wrote:
> The "split" routine in the RandomGen seems to be a sore spot for some
> people and is perceived to have few users (even as a percentage of
> RandomGen users).  I propose:
> 
> 1) Making a class "SplittableGen":
> 
> class SplittableGen g where
>   split :: g -> (g, g)
> 
> 2) (re)moving the "split" routine from the RandomGen class.
> 
> See ticket 4314 [1] for the patch.

There has been reasonable discussion on this (20 messages by my count).
Responses seem to break down into 3 unknown, 1 against, and 7 for some
sort of change:

Yes, and add extra change X (BOS)
Yes (Duncan, Ian, TomMD)
With a modification to the class structure (Henning, Felipe, Nicolas)
No, this breaks things without cause (Milan)
Unknown/neutral (Isaac, Ivan, Brandon)


I'd say the "Yes" and "with modification" votes have it.  As it's pretty
close (4 - 3) with one group calling or a "clean split" and the other
calling for change that is backward compatible, a last round of
discussion that might bring more peoples thoughts in could be
beneficial.  Discussion still ends on the 8th so I will re-summarize and
make a patch this weekend.


The two positions:

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).

Cheers,
Thomas

P.S. My position hasn't changed and I have nothing more to add to what's
been said, see the threads history for any refresher.