the fuzzy and slightly out of date task list in 
https://github.com/haskell/random/issues/31
sketches out some of the basic stuff (though theres more confusion than clarity in the discussion thread on that ticket)

for my own peace i'm doing most of the v2 work over at https://github.com/cartazio/random, and i've been focusing on internals before sussing 

the API will have a breaking change even if we were types compatible because the meaning of the seed stats will no long provide the same computations

the v2 series will provide splitmix and pcg RNGs, a MonadRandom class that doesn't require a PrimMonad constraint for pure generators. 

per commit CI will end up running small crush and determinism checking tests once its at a stable/more mature point, and per RELEASE CI will do a big crush run or several on various permutations of the tools

thats ignoring having good benchmarks for how well different RNGS and implementation strategies thereof

I've also had some productive chats with tomdb of Galois about what the end state should be. 

I think for all practical purposes this thread is a waste of time. 

On Wed, Jan 25, 2017 at 2:55 PM, Sven Panne <svenpanne@gmail.com> wrote:
2017-01-25 13:47 GMT+01:00 Dominic Steinitz <dominic@steinitz.org>:
[...] I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action. [...]

This is not what I have proposed: My proposal was: Add any number of RNGs in one or more packages, but keep the current API of System.Random in package "random". It should probably use (= re-export, perhaps with a shim) one of the other, better RNGs to address the problems you've mentioned.

Breaking/removing fundamental packages should not be done light-heartedly, it wreaks havoc in the ecosystem. Look e.g. at the reverse dependencies of "random" (http://packdeps.haskellers.com/reverse/random): There are 845 packages affected, and I'm not even sure if that page takes transitive dependencies into account. Assuming that hundreds of package maintainer will happily update their packages in a short time frame just to use something "better" (where "better" is probably very dependent on one's POV) is overly optimistic. And in addition, doing such breaking changes obsoletes documentation, tutorials etc. out there. Yes, I'm repeating myself, but this is a point which seems to be forgotten quite often.

Is there something in System.Random's API which is fundamentally broken? I'm not sure, and I'm by no means an expert in RNGs. If yes, we should nevertheless keep it for now, probably deprecating the broken parts and phase them out slowly. Processes like this are quite slow (measured in years), and there are many good reasons for this. Looking e.g. at Java's java.lang.Thread.stop() one can see that it is still in the latest JDK, although it has been deprecated for almost 2 decades now. Another example is C++'s horrible pre-exception I/O standard library, something which everybody hates, but it is still there, after an even longer time.

Cheers,
   S.

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries