<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-01-25 13:47 GMT+01:00 Dominic Steinitz <span dir="ltr"><<a href="mailto:dominic@steinitz.org" target="_blank">dominic@steinitz.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">[...] 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. [...]<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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" (<a href="http://packdeps.haskellers.com/reverse/random">http://packdeps.haskellers.com/reverse/random</a>): 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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>   S.</div></div></div></div>