Raw I/O library proposal, second (more pragmatic) draft

[Ashley Yakeley]

In article 
<3429668D0E777A499EE74A7952C382D1A5E237@EUR-MSG-01.europe.corp.microsoft
.com>,
 "Simon Marlow" <simonmar@microsoft.com> wrote:

> 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