[Haskell] System.Random

[Glynn Clements]

Wolfgang Jeltsch wrote:

> > >>why is the Random module situated under System?  Wouldn't
> > >>something like Data be more adequate?
> > >
> > > There is usually an external source of randomness, which is why the
> > > library in placed in System rather than Data.  A purely functional
> > > random library would be rather less useful...
> >
> > Now, I don't understand this at all...
> >
> > All the development of the Random stuff in all languages has nothing
> > of random whatsoever. Perhaps *some* people like to seed the generator
> > with the clock time, but most *real* developers *known to me* usually
> > choose the seed deterministically, in order to reproduce the sequence,
> > until the program is ready to run in the end-user environment.
> >
> > Anyway, conceptually, the behaviour of random generators is very far from
> > any "external source of randomness", so the question 'why "System"' for
> > me remains valid. The module Random might of course use Time or similar
> > entities for the randomization/initialization, but this is a contingency.
> 
> Yes.  My question was based on the fact that most of the stuff in Random has 
> really nothing to do with the system.  The main random stuff is purely 
> functional.  Things like getStdGen are rather nice additions to the core 
> stuff.

There are two issues here:

1. The initial global_rng is seeded using getRandomSeed, which uses
the IO monad.

2. {get,set,new}StdGen and getStdRandom use an IORef to hold the
current generator, which uses the IO monad.

1 is a bad idea, IMHO. It should be seeded to a fixed value, like ANSI
C's rand(). The user can seed it from the clock (or similar) if they
don't want repeatability.

Once you remove the hardcoded getRandomSeed, 2 is also also a bad
idea; it could just as well use an STRef (ST can be safely lifted to
IO, but the reverse requires unsafePerformIO) or even just MonadState.

Note that the choice of monad is "contagious", due to the presence of
randomIO and randomRIO in the definition of Random. These should
probably be plain functions rather than class methods.

-- 
Glynn Clements <glynn.clements at virgin.net>