Proposal: Generalize the RandomGen and Random classes

[Thomas DuBuisson]

2010/10/6 Milan Straka <fox at ucw.cz>:
> I do not object to a change, but as I said in the paragraph above the cited
> one, I do not see much benefit (so I consider breaking this code
> a bigger issue than gain from accepting it).

Sorry for the misrepresentation.

> Let me repeat my question:
> - what other types than Int do you have in mind? (also asked by Antoine
>  Latter)
> It seems to me that bits can be trivially converted to Ints.

I like the idea of generating bytestrings - this is evidenced by my
API in Crypto.Random.  At the same time, I can understand not making
"random" depend on "bytestring" being important, which is why I made
the class flexible in generated type (and not a bunch of "nextTypeX"
routines as Antoine brought up).  Other packages seem to generate
Double and do so with speed.  One can imagine a world where bytestring
falls out of favor (PackedString will never die!) for the next
packaging.

> Personally I also do not like Functional dependencies very much. I would
> rather be in favor of type families, as SPJ suggested.

I don't have a dog in this fight, aside from Mark Jones controlling
some of my grades, pay check and ability to advance in my academic
career ;-).  Seriously, I'll go with whatever.  I thought FDs were
still the thing for base libraries but if they aren't then I'll make a
TF based patch.

Antione said:
> I guess the new class interface feels somehow off to me.
... proposes "nextInt32", "nextDouble", etc ...

I'm all for considering other interfaces, but I can't figure out how
to make a clean interface that allows arbitrary types to be generated.
 What happens when I can generate ByteString?  And how about Vector?
We don't want the "random" package depending on these others and we
dont' want users to 1) not user Random when it should still make sense
2) Use random in some ugly manner such as: rand = pack . gen when gen
= unpack . backendGen.

Cheers,
Thomas