Random Number Update

[Niklas Hambüchen]

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 <amindfv at gmail.com <mailto:amindfv at 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... ;-)