Fergus Henderson wrote:
>
> On 04-Feb-2000, Matt Harden <[EMAIL PROTECTED]> wrote:
> > >
> > > > class RandomGen g where
> > > > next :: g -> (Int, g)
> > > > split :: g -> (g, g)
> > > > genRange :: g -> (Int, Int)
> > > > genRange _ = (minBound, maxBound)
> >
> > Simon, do you think we could have the *optional* genRange described
> > above? If that approach is chosen, then the changes to GHC and Hugs
> > are rather painless.
>
> I think that's probably the best thing to do in the long run.
In the long run (Haskell 2), I'd like to consider some bigger changes,
which I won't get into here.
> And in the short term, it may well be the easiest thing to do,
> at least as far as ghc and Hugs are concerned.
>
> What about the other Haskell implementations?
> Do any of them implement the Haskell 98 Random module yet?
> If so, do they generate the full range minBound .. maxBound,
> or do they generate something different?
The NHC98 Haskell compliance page says this:
>> Some of the new Library functions remain unimplemented. (Runtime
>> warnings are provided for all unimplemented functions.) The main
>> functions missing are in Directory, Random, Time, CPUTime, and a
>> few from IO.
I'm going to assume that means they haven't implemented the new Random
spec yet.
I just downloaded HBC-0.9999.4, and their Random.hs is the old style (no
RandomGen at all). The HBC snapshot from September 1999 contains the
Random.hs code from GHC/hugs. It also has the old Random.hs from
0.9999.4. I can't find an "official" HBC-0.9999.5 source release, which
is supposed to be the Haskell 98 compliant release.
There could of course be other implementers of genRandom out there who
may not have released their code yet. There's not much we can do about
that, I guess, except try to bring attention to the change.
> Note that the optional genRange method is only optional
> as far as the implementor of a RandomGen instance is concerned.
> For the user of a RandomGen, it is not optional, in the sense that
> if we add the genRange method, then users who want code using
> that class to have the correct behaviour will have to make use
> of that new method.
Good point. OTOH, you (Fergus) and Tom Pledger pointed out earlier that
the user of next *can* get by without knowing the range. People who use
a clever hack like that can just ignore genRange, and things will
continue to work for them just as before.
> However, the most common uses of the RandomGen
> class would be indirect, via the Random class, so probably there
> is not much code which would depend on this.
I completely agree with that. Anyone who was trying use RandomGen
directly, whether trying to implement a new RandomGen instance, as I am,
or using the next operation directly, would probably have run into the
same problems that I did. If they assumed the range was [minBound,
maxBound] they'd be in for a surprise in GHC/hugs, which is probably the
only RandomGen implementation out there anyway. If they didn't make any
assumptions about the range, and still came up with something useful, it
will still work even if genRange is added to the spec.
Regards,
Matt Harden
