In article
<3429668D0E777A499EE74A7952C382D1A5E237@EUR-MSG-01.europe.corp.microsoft
.com>,
"Simon Marlow"
What would be the motivation for abstracting over the monad type?
It might be useful to use streams with other monads, such as lifted IO monads, or simple state monads such as "s -> (s,a)". The idea is that your stream classes might be useful in other contexts.
IMHO, it has to be done consistently or not at all. That is, *all* our IO code should be abstracted over the monad,
Not necessarily. It could just be the three classes that are general, and the types are specific to whatever monad. There's no doubt that opening a file is an IO-based action, it could never safely be done in the Maybe monad. The classes, however, are patterns that might apply to many situations. The downside is that all the stream types have to have a dummy monad parameter, which might be considered slightly ugly. It's a trade-off, and given that we're constrained by Haskell 98's lack of multiparameter type-classes, I can see arguments on both sides of it. I also think the data-structure idea might be worth examining, it seems to me it's basically making the class context dictionary explicit. But it seems Haskell libraries don't do a lot of that for some reason. Probably the big downside is that it's hard to extend later -- your fileOutputStream function has to return a structure containing everything that can be done with the stream. You can't add new functionality to a FileOutputStream later on, as you could if it were an opaque type that were a member of a class. -- Ashley Yakeley, Seattle WA