Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#4315 closed proposal (wontfix)

Generalize the 'RandomGen' and 'Random' classes

Reported by: TomMD Owned by:
Priority: normal Milestone: Not GHC
Component: libraries/random Version: 6.12.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by igloo)

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 my types easier than coercing to Int then to an 'a' via the Random class.

The proposal is to change the classes from/to:

    class RandomGen g where

  -->

    class RandomGen g v | g -> v where

and

    class Random a where

  -->

    class Random a v where

And make needed changes to the classes instances that follow from these.

Attachments (2)

GeneralizeRandomAndRandomGen.patch (8.6 KB) - added by TomMD 5 years ago.
Generalize Random and RandomGen
VersionBump.patch (1.4 KB) - added by TomMD 5 years ago.
Bump to version 1.1

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by TomMD

Generalize Random and RandomGen

Changed 5 years ago by TomMD

Bump to version 1.1

comment:1 follow-up: Changed 5 years ago by TomMD

Note: The attached patch is built on a repo with the patch from bug 4312.

comment:2 in reply to: ↑ 1 Changed 5 years ago by TomMD

Replying to TomMD:

Note: The attached patch is built on a repo with the patch from bug 4312.

Sorry, I ment the patch from proposal #4314

comment:3 Changed 5 years ago by igloo

  • Description modified (diff)
  • Milestone set to Not GHC

comment:4 Changed 5 years ago by TomMD

  • Resolution set to wontfix
  • Status changed from new to closed

comment:5 Changed 5 years ago by TomMD

In summary to this proposal, I think the community agrees it is too "cludgy". Perhaps people would have agreed on one of SPJs suggested designs [1], so I might make another proposal when I again have time. I'll mark the associated bug as closed, or whatever seems closest to 'reject'.

Cheers, Thomas

[1]

 class RandomGen g where
    type GenVal g :: *
    next :: g -> (GenVal g, g)

 class Random a v where
   randoms :: forall g. (RandomGen g, v ~ GenVal g) => g -> [a]

or

 class RandomGen g where
   nextInt :: g -> (Int, g)
   nextByteString :: g -> (ByteString, g)
Note: See TracTickets for help on using tickets.