| The discussion of random numbers in Haskell should perhaps
| move elsewhere as it is quite restricted, but it shows one
| problem with the functional approach to *practical* programming:
| in *my opinion* our fascination by the Monadic Approach to
| Universe and Everything, and the possibility to program in an
| imperative way has a negative side effect. My friends physicists
| asked me once after being told that imperative constructs are
| possible in Haskell: "so, what's the point in using this language?
| Fortran code is simpler than "do" in Haskell..."
Huuuh. Did you tell your friend that imperative constructs are the
`only' thing possible? Surely not. So I don't quite understand this
statement (on a scientific basis).
| I would change the
| Lennart example by using splitAt instead of take, and continuing the
| next
| instance with the remaining part of the master sequence.
But now you are basically programming within a state monad, the
infinite sequence of pseudo-random ints being the state. At its
simplest:
let (is1, ms1) = splitAt m ms
(is2, ms2) = splitAt n ms1
vs
do is <- ints m
ds <- doubles m
However, having re-thought the whole thing I guess it's a good idea to
use an infinite stream as the state instead of the seed. As you
remarked in a previous mail this would make it simple to provide a
different generator. Nonetheless, I still believe that using a monad
(note necessarily IO) is the RIGHT approach, because the state is
passed implictly and it allows to hide the technical details (how many
Ints do you need for an Integer in the range (l,r)?) from the user.
Cheers, Ralf
