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

Maciej Piechotka uzytkownik2 at gmail.com
Thu Jul 2 17:05:05 EDT 2009


On Thu, 2009-07-02 at 14:18 -0600, Luke Palmer wrote:
> On Thu, Jul 2, 2009 at 5:31 AM, Maciej Piechotka
> <uzytkownik2 at gmail.com> wrote:
>         2. I find writing monad transformers annoying.
>         Additionally if package defines transformer A and another
>         transformer B
>         they need to be connected 'by hand'.
> 
> You have not given any concrete problems or examples, so it's hard for
> me to comment.  But at first glance, I would conjecture that you are
> relying too heavily on monads and sequential thinking.
> 
> Consider what your code would look like without a single monad.
> Obviously you cannot talk to the network without IO, but your program
> can still be modeled purely, and then toss in IO at the last second to
> tie it to the network.  This model may be difficult for you because it
> requires your brain to be rewired; feel free to mail this list with
> concrete modeling problems and we will help you out.
> 
> As for the pure model, throw away Reader, Writer, State -- everything,
> and just use pure functions.  Then add monads back in at small scopes
> when they clean things up. 
> 

AFAIU you comment the 2de point only. I look at this moment from
library, not program point of view.

So consider the library IOMonad which defined some MonadInput v m monad.
Then you have NNTP library which has NntpT m monad.

Each of them defines appropriate stack such as that NntpT (State s) is
instance of MonadState. But if there is NntpT MyInput, where MyInput
isinstance of MonadInput, is not MonadInput. To do it with current
approach the libraries would have to be interlinked.

Also it is quite boring to include for all monad
instance ... => ... where
    f1 = lift f1
    f2 = lift f2
    ...

> I used to approach problems by designing a monad for my whole program,
> using an appropriate stack of transformers.

I thought about others which might have want to use my monads in their
functions...

> I suspect such an approach led to the claim that "monads are not
> appropriate for large software systems" in a popular paper a few
> months ago.

I'd appreciate the link - google find nothing. I fall in love in Haskell
about a week or two ago and I fall in love just after I started learning
it ;)

> As I have gained more experience, I found that this is the wrong way
> to go about using them.  Now my primary use of monads is within the
> scope of a single function, to tie together the helper functions in
> the where clause.
> 
> Luke
> 

Regards



More information about the Haskell-Cafe mailing list