<div><div class="gmail_msg">the fuzzy and slightly out of date task list in <div class="gmail_msg"><a href="https://github.com/haskell/random/issues/31" class="gmail_msg" target="_blank">https://github.com/haskell/random/issues/31</a><br class="gmail_msg"></div><div class="gmail_msg">sketches out some of the basic stuff (though theres more confusion than clarity in the discussion thread on that ticket)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">for my own peace i'm doing most of the v2 work over at <a href="https://github.com/cartazio/random" class="gmail_msg" target="_blank">https://github.com/cartazio/random</a>, and i've been focusing on internals before sussing </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">the v2 series will provide splitmix and pcg RNGs, a MonadRandom class that doesn't require a PrimMonad constraint for pure generators. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">thats ignoring having good benchmarks for how well different RNGS and implementation strategies thereof</div><div class="gmail_msg"><br></div><div class="gmail_msg">I've also had some productive chats with tomdb of Galois about what the end state should be. </div><div class="gmail_msg"><br></div><div class="gmail_msg">I think for all practical purposes this thread is a waste of time. </div></div></div><div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Jan 25, 2017 at 2:55 PM, Sven Panne <span class="gmail_msg"><<a href="mailto:svenpanne@gmail.com" class="gmail_msg" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">2017-01-25 13:47 GMT+01:00 Dominic Steinitz <span class="gmail_msg"><<a href="mailto:dominic@steinitz.org" class="gmail_msg" target="_blank">dominic@steinitz.org</a>></span>:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">[...] 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 class="gmail_msg"></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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" class="gmail_msg" target="_blank">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,</div><div class="gmail_msg">   S.</div></div></div></div>
<br class="gmail_msg">_______________________________________________<br class="gmail_msg">
Libraries mailing list<br class="gmail_msg">
<a href="mailto:Libraries@haskell.org" class="gmail_msg" target="_blank">Libraries@haskell.org</a><br class="gmail_msg">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div>
</div>