Proposal: Generalize the RandomGen and Random classes
thomas.dubuisson at gmail.com
Wed Oct 6 18:53:13 EDT 2010
There has been precious few comments on this proposal (ending in 2
days). Conversation has thus far been:
Accept (1 - me)
No - Random is H98 and changing it is not acceptable (2 - Milan, Yitz)
Unknown Stance (2 - SPJ, Antonie Latter)
Mostly I'm hoping for more comments. If you found the splittable
debate of value then I'd imagine this aspect of Random would concern
In response to the idea that we can't or shouldn't change H98:
> If those extensions
> are all added to Haskell 2011 or whatever, then it could be considered.
AFAIK, all accepted parts of Haskell standards are implemented FIRST
(typically as a GHC extension or package) then considered for
Haskell'. The Haskell2010 and Haskell98 packages, which you can
import, can contain their own definition of System.Random - this could
be static without stagnating all libraries that are mentioned in a
> I personally do not think it is worth to modify the Random module, which
> dates back to at least Haskell 98. Maybe a new package on the Hackage?
So because it is old we can't modify it? The point of changing the
library is to benefit a broader portion of the community. We could
stop any and all changes to package X and make a new package every
time but this isn't a sufficient argument to me.
If peoples only objections are compatibility then we can queue this
change up with the next API breaking change, unless there will never
again be such a change.
On Tue, Sep 14, 2010 at 5:11 PM, Thomas DuBuisson
<thomas.dubuisson at gmail.com> wrote:
> RandomGen and Random classes assume generators produce Int values.
> This is non-ideal as many high speed generators produce special values
> (ex: doubles) or generic values (bit streams / bytestrings) that can
> be converted directly to types easier than coercing to Int then to an
> 'a' via the Random class.
> See 4315  for the patch.
> Period of discussion: Till October 8 (3.5 weeks, giving a little time
> after ICFP for last minute debate)
> Specifically, this proposal:
> 1) Alters RandomGen:
> class RandomGen g where
> next :: g -> (Int, g)
> genRange :: g -> (Int, Int)
> class RandomGen g v | g -> v where
> next :: g -> (v, g)
> genRange :: g-> (v,v)
> 2) Alters Random:
> class Random a where
> randomR :: RandomGen g => (a,a) -> g -> (a,g)
> random :: RandomGen g => g -> (a, g)
> randomRs :: RandomGen g => (a,a) -> g -> [a]
> randoms :: RandomGen g => g -> [a]
> randomRIO :: (a,a) -> IO a
> randomIO :: IO a
> class Random a where
> randomR :: RandomGen g v => (a,a) -> g -> (a,g)
> random :: RandomGen g v => g -> (a, g)
> randomRs :: RandomGen g v => (a,a) -> g -> [a]
> randoms :: RandomGen g v => g -> [a]
> Additional Points of Debate
> 1) Because random[R]IO can not be part of the new Random instance with
> a sensible default, these have been moved to top-level functions:
> randomRIO :: (Random a Int) => (a,a) -> IO a
> randomIO :: (Random a Int) => IO a
> Other options exist and I'm open to them. I'm just being upfront
> about what the patch currently does.
> 2) All pre-existing instances of "Random x" for some concrete 'x' have
> been modified to be "instance Random x Int". As 'Int' was the
> previous (hardcoded) default for RandomGen this is simply matching the
> behavior. More instances are possible and probably make sense now.
> Alternatively, one could argue for zero default instance as they can
> collide with how a particular user wishes types to be coerced.
> 3) Not-so-new extensions are used to enable these changes. Extensions
> include MultiParamTypeClasses, FlexibleContexts, and FunDeps.
> 4) A patch is included bumping the version from 1.0.0.x to 220.127.116.11.
>  http://hackage.haskell.org/trac/ghc/ticket/4315
More information about the Libraries