Re: Improve `seed->random-state' in stable-2.0?

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

> On Fri 20 Jan 2012 19:52, Mark H Weaver <address@hidden> writes:
>
>> We have a 64-bit PRNG, but even if you make sure to seed it with a
>> number that has plenty of entropy, `seed->random-state' will only
>> preserve around 32 bits of it.
>
> Wow, that's horrible.  Agreed that this needs fixing.
>
> How about, we extend seed->random-state to operate on bytevectors, and
> have that interface do the right thing.

I agree that it would be nice for `seed->random-state' to support
bytevectors as well, but for many (most?) purposes that would be a very
awkward interface to use.

> We deprecate the number interface.  At some point in the future we
> deprecate the string interface as well.

I think this would be very unfortunate.  Numbers are by far the most
natural representation for seed values, and I hope they will continue to
be fully supported.

> I'm hesitant to make seed->random-state change the rstate that it
> produces, for a given seed.  It's unlikely anyone is relying on this,
> but who knows...

Even if we keep a broken `seed->random-state', there's another problem:
our PRNG sucks rocks.  If we constrain ourselves to produce the same
sequence of random numbers for a given seed, that means that we're stuck
with this very weak PRNG for the entire 2.0 series.

Can't we just make a clean break now?  2.0 is still not widely deployed,
so now is a great time to assert our right to change the PRNG at will.
As you say, it's unlikely that anyone is relying on this anyway.
If anyone is, wouldn't it be better to deal with that now?

    Thanks,
      Mark