
I'm a bit late to the party. Deprecating random, or functions/generators within it, does not conflict with backwards compatibility in my opinion. If there's something that doesn't quite work as we'd like it, we can still keep it forever with a DEPRECATE pragma, and better functions get new names. Java has been doing that successfully for a long time, with some functions being deprecated and still working for 20 years. You just get that very useful warning when you use them. In fact, I believe that deprecation is the only correct way to bring in new generators into any random package, because you cannot replace a pure RNG by a better RNG without breaking lots of people's code. When you use a pure RGN, you rely on it giving the same output given the same seed, to be referentially transparent, without exception, forever in the future, also across library version upgrades. If a random gen was replaced under my feet, lots of my tests would break that way. I thus find Dominic's proposal to deprecate what doesn't work as supposed the right thing. If this happens by deprecating the package, or by deprecating functions from that package, is a technicality to me, and I would prefer whatever gives better warnings (I believe this is currently deprecating functions as that gives GHC warnings, while as to my knowledge no tooling warns you if you use a deprecated package). Niklas On 24/01/17 20:45, Sven Panne wrote:
2017-01-24 18:33 GMT+01:00
mailto:amindfv@gmail.com>: Carter, can you outline how random v2 compares to v1?
Whatever will be done, I think it would be good to keep the 'random' package alive, probably just by re-exporting one of the better RNGs, perhaps with a thin shim to keep the API identical. Yes, this would somehow "bless" one of the RNGs, but this is not important: The important thing is avoiding breakage in the ecosystem, keeping tutorials, books etc. valid. People who know what they are doing can easily pick the right RNG for their needs and/or quickly adapt their code, but I guess for lots of stuff having just *some* RNG under the traditional package name/module name is more than enough.
Just my usual backwards-compatibility-rant... ;-)