Arrows versus Monads

So, haskell uses monads to do IO. Monads are very confusing to most people. Arrows are a generalization of monads, so one would expect that arrows would be even more confusing. However, once I read the arrows paper, which explains how arrows can model stream processors, arrows suddenly seemed like the most natural thing in the world.

This probably has something to do with the fact that I spend nearly all my time at work thinking about stream processing. For example, even the definition of "first" is pretty intuitive to me -- at work, we call the analogous concept "pass all".

Other than the fact that I spend most of my day working on stream processing, I think part of the reason I find arrows more intuitive than monads is because arrow composition combines arrows with arrows, while monad composition combines monads with functions. The asymetry makes monads hard to understand for two reasons:

• You have to think harder in order to understand how to preserve the monad part of your values, since the function takes a non-monadic value.
• Unless you're familiar with the fact that the return type of a haskell function can depend on its calling context, it's not at all clear how the function knows what kind of monad to wrap its return type in.

In contrast, the arrow >>> function is immediately obvious, just by looking at its type signature:

a b c -> a c d -> a b d

I mean, can there be any clearer way to express composition?

Posted on June 7, 2005 04:52 PM
More languages articles