Any generic API will need to define set of primitive generators which are used to define more complicated ones. Question of what this set should include are largely independent from other details of API and as such could discussed separately. In examples I assume some variant of monadic API

Proposal from #1

   genWord8  :: m Word8
   genWord16 :: m Word16
   genWord32 :: m Word32
   genWord64 :: m Word64
   genFloat  ::  m Float
   genDouble :: m Double

Basically this includes generators for all fixed width ints and for IEEE754 floats.

Whether floating point should be included

@Shimuuar: no

Offhand I can say that I think Float & Double shouldn't be part of interface. They are trivially derived from uniform Word32/Word64. And there's problem: are we generating in [0,1] range? (0,1]?

@cartazio ???

There’s several gotchas with those algorithms for float and double.

The usual unit interval used in extent Haskell Libs is wrong.

See the commented out bit linked herein
https://github.com/haskell/random/blob/master/src/Data/Distribution/FloatingInterval.hs

https://github.com/haskell/random/blob/master/src/Data/Distribution/FloatingInterval.hs

@lehins leans to no

With regards to floating point numbers I am leaning towards not including them for consistency with ranges. Having a single efficient implementation for all RNGs that use either 32bits or 64bits seems like a better idea

So far it looks like general consensus is to make generators for floating point numbers derived.

Inclusion of ranges

Another proposal by @Shimuuar, genWord32R n generates values in range [0,n] inclusive.

   genWord32  :: m Word32
   genWord32R :: Word32 -> m Word32
   genWord64  :: m Word64
   genWord64R:: Word64 -> m Word64

Arguments for inclusion genWord32/64R:

• Some PRNG (e.g. LCG) generate randoms in range other that full Word32/Word64. Implementing genWord32/64R in terms of
• Even if PRNG produces uniform Word32/64 optimal implementation of genWord32R depend on whether generator produces Word32 or Word64
• @lehins argument in support of nextWord8/16 could interpreted as support of *R variants: "We should allow a specific RNG to decide what is the most efficient way to generate 8 and 16 bits of random data". If PRNG should be able to decide what is best way to generate Word8, e.g. range [0,255] it should be able to decide how to generate other ranges

Argument for excluding genWord8/16:

They're subsumed by genWord32R: genWord8 = getWord32R 255
Argument for inclusing genWord8/16:
We should allow a specific RNG to decide what is the most efficient way to generate 8 and 16 bits of random data