[Haskell-cafe] Re: Monad Input/Output and Monad Transformers

John Lato jwlato at gmail.com
Fri Jul 3 05:48:37 EDT 2009


> From: Maciej Piechotka <uzytkownik2 at gmail.com>
>
> 1. Learning haskell I discovered that I/O should be avoided nearly 'at
> all costs'. The problem is that the IO monad is the only one which have
> more interactive work flow. There is Reader/Writer monad but in fact
> AFAIU first one is about the environment and second one is about
> logging. Implementation of Writer can be defined in terms of handles but
> it is rather limited (either non-full implementation which may be
> confusing or need of caching the result for pass etc.).
>

I'm not sure what you mean when you say that IO is the only monad with
a "more interactive work flow".  Do you mean that it allows
interleaving of input and output?  If so, I would ask what you're
doing that makes this a concern.

If it's for efficiency, don't worry about it.  Haskell's laziness
means that the language will take care of this for you.  A good
example is the bzlib[1] package; the "compress" function has type
"ByteString -> ByteString" and automatically handles the chunking of
data for you.

If you need to partially process an input to determine how the rest of
the input should be handled, there are many parser libraries
(parsec[2], polyparse[3], etc.) that can either help with this
directly or perhaps give ideas as to how you can handle it.

You may also want to look at the iteratee[4] package.  It sounds like
it may accomplish what you're trying to do, although the interface is
very different from what you specify.

>
> 2. I find writing monad transformers annoying.
> Additionally if package defines transformer A and another transformer B
> they need to be connected 'by hand'.
>

If this becomes onerous, I think the usual solution is to define
custom lifting functions for the most commonly performed operations.
However, my feeling is that you're probably trying to put together a
monad stack to model what you're trying to do too soon, when you'd be
better served trying to develop data structures and core functions
that describe what you want to do.  Of course, without more
information this is just a guess.

John Lato

[1] http://hackage.haskell.org/package/bzlib
[2] http://legacy.cs.uu.nl/daan/parsec.html,
http://hackage.haskell.org/package/parsec
[3] http://www.cs.york.ac.uk/fp/polyparse/,
http://hackage.haskell.org/package/polyparse
[4] http://okmij.org/ftp/Haskell/Iteratee/,
http://hackage.haskell.org/package/iteratee


More information about the Haskell-Cafe mailing list