2010/10/6 Milan Straka
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