On Jun 3, 2010, at 10:03 PM, wren ng thornton wrote: > Though, since RVar is a synonym for RVarT, I can't imagine why rvar is a > method instead of a shorthand defined outside of the class. (If RVar were > primitive then I could imagine performance reasons, but since it isn't...)
The reason for this is purely a matter of convenience combined with a bit of historical accident and/or laziness. The RVar type predates the RVarT type, and thus rvar predates rvarT as well. My personal idioms for defining distributions were invented before RVarT and have been slow to change. These idioms involve defining the 'rvar' implementations in terms of the public interface of simpler distributions, which are mostly exporting plain 'RVar's in order to reduce the need for type annotations fixing 'n' elsewhere. 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). 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. Suggestions are welcome :) -- James_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
