[Haskell-cafe] ANN: random-fu 0.1.0.0

[wren ng thornton]

James Andrew Cook wrote:
> In particular, functions such as 'uniform' and 'normal' which directly construct RVars are very useful in defining the rvar implementation of other types.  I have been reluctant to drop the rvar function from the Distribution class because it is very useful to be able to define other Distribution instances in terms of these functions instead of the uglier explicit use of rvarT - e.g. "rvarT StdUniform" in place of just 'stdUniform'. Eventually I'll probably give up this particular objection – probably sooner rather than later now that you've made me think about it – but I'm presently in the state where I know it isn't "right" to have both (for some value of "right")  but I don't know yet what a better solution is, given my conflicting objectives (one of which is to refrain from changing everything at once, so users have a chance to keep up with the library's evolution).

Oh I'm sure writing the rvar implementation is prettier. However, since 
clients have to define rvarT too, they can't escape the ugliness :)

If RVar were a datatype, then I could imagine there being performance 
reasons for wanting to define them separately. However, since it isn't, 
it seems like having both methods in the class is just begging for code 
duplication and inconsistency bugs. Without the performance benefit, I 
can't see a reason for having both---

     ---unless, perhaps, you have a way of deriving a definition of 
rvarT from rvar. If so, then there could be efficiency issues in the 
other direction. I could see some people just giving a pretty 
implementation of rvar and using the inefficient rvarT, whereas other 
people would put up with the ugly in order to have an efficient rvarT... 
(I haven't looked at the package to know if this is actually a possibility)


> Making the convenience functions mentioned above return RVarT seems natural, but when I tried it I found it made their usage require type annotations in many other places to fix the type of the underlying monad, and I have not yet decided whether it is worth all that.  I may yet introduce separate RVarT-typed convenience functions as well, but I'm not sure I want to do that either.

That's what I was going to propose :)

You could define the RVarT versions, but then keep the RVar versions 
around for their restricted type. That would allow for moving rvar out 
of the class (eliminating possible code duplication bugs) and still 
allow for using uniformT, normalT, etc when defining rvarT.

-- 
Live well,
~wren