On Jun 4, 2010, at 9:42 PM, wren ng thornton wrote: > ---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) >
This is precisely the present state of affairs, and I'm probably the worst offender. In fact, most of the distributions provided in the library just use the default implementation of rvarT, which as you guessed has a bit of a penalty associated. I've had it in the back of my mind for quite a while to revisit that design, it just hasn't been enough of a priority to actually do it. I've been having more fun mucking about in the numerical code :) > >> 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. > Yea, now that you put that in words, I like the idea and see that it wouldn't be as disruptive as I subliminally assumed. I'll probably get to it sooner rather than later - thanks! -- James_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
