Random Number Update

[Sven Panne]

2017-01-25 13:47 GMT+01:00 Dominic Steinitz <dominic at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170125/1d2bc806/attachment.html>