genBits: small addition to random API + largely new implementation that needs code review

[Ryan Newton]

Good point about the entropy source.

I like how the mersenne-random-pure package for instance provides an IO
function to get a RNG from the system clock:

http://hackage.haskell.org/packages/archive/mersenne-random-pure64/0.2.0.3/doc/html/System-Random-Mersenne-Pure64.html

I think it makes sense to have a similar call both as a place to put better
entropy sources for certain platforms, and to make it maximally easy for the
user to do the right thing.  (I imagine there are many instances of people
using a constant -- and probably one with lots of zeros -- to initialize
mkStdGen).

-Ryan

On Tue, Jun 28, 2011 at 6:01 PM, Thomas DuBuisson <
thomas.dubuisson at gmail.com> wrote:

> Ryan Newton <rrnewton at gmail.com> wrote:
> > There implementation has two major pieces:
> >     (1) Sources of random bits (class RandomGen)
> >     (2) Instances of class Random that map use random bits to create
> Haskell
> > types
>
> I'd say there are three pieces, initial entropy (clock, external seed,
> system crypto random generator), deterministic generator interface
> (PRNG, the RandomGen class), and the instances of that class.
>
> I tried to answer the first item in System.Crypto.Random.  The 'random'
> package
> never really had an answer for entropy and I'm not sure what the
> community thinks about that.  Perhaps answering this problem in slightly
> obscure packages is OK.
>
> > The issue is
> > that the legacy RandomGen API isn't very good at generating random bits.
>
> Agreed.  This is why CryptoRandomGen uses ByteString (so we can
> generate any number of BYTES of random values).
>
> As I tried to argue when I make RandomGen more polymorphic, this is an
> issue with hardcoding the type as Int.  Unfortunately, people didn't
> accept that alteration and I feel continuing to generating Int while
> allowing devs to discover the amount of entropy isn't taking things
> far enough.
>
> > I'd also be happy to hear other proposals for API changes and additions.
>
> As I say below, I don't understand why we can't use ByteString.  There
> are (or should be) rather fast decodings of all the popular primitive
> types from bytestrings, so this takes care of our polymorphism issue.
>
> I accept that, unlike the CryptoRandomGen, we don't want an explicit
> failure for RandomGen.  But how about a common interface for
> instantiating generators ('newGen')?  Is there a reason not to have that?
>
> --- CODE ---
> class RandomGen g where
>    next :: g -> (Int, g)
>    nextBits :: g -> BitLength -> (ByteString, g)
>    genBits :: g -> Int
>    newGen :: ByteString -> g
> --- END CODE ---
>
> Also, perhaps we could still have an explicit reseed?
>
> --- CODE ---
> class Reseedable g where
>    reseed :: g -> Bytestring -> g
> --- END CODE ---
>
> I'll stop here before I entirely recreate CryptoRandomGen, but without
> the explicit errors and in more classes (the next step would be a method
> for querying how much entropy is needed for instantiation).
>
> >  System.Random can't depend on bytestring, so I doubt we want block RNG
> in
> > the RandomGen class.
>
> Why can't it?  System.Ranomd isn't part of H2010 and H98 already needs
> its own random module.
>
> I'll try to make time to review the code, you'll hear if I do.
>
> Cheers,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110628/aa19c83a/attachment-0001.htm>