[Haskell-cafe] Re: Arrows and Haskell

[Peter Simons]

Since I have been experimenting with Arrows quite a bit just
recently, I feel compelled to add something to the
discussion.

I too think that Arrow are a beautifully simple and elegant
concept. However, once you write production code, you notice
quickly that there is a significant difference between a
code snippet that's been chosen specifically to illustrate
the beauty of Arrows and something else.

In my (albeit limited) experience, Arrows are not the answer
"to it all" any more than any other clever software design
technique is. The moment you need to do things like "apply"
an Arrow, you are squarely in the domain of Monads again. So
why not write a Monad to begin with?

Plus, powerful abstractions that make the code look simple
and elegant _always_ come at a price. An Arrow-based stream
processor that performs the same task as my monadic BlockIO
library does, for instance, results in a module that has
half the size the StateT version does. Which is cool. But it
is, as of now, also 10 times slower than the monadic version
is. Which is not cool at all.

It is quite likely that I don't understand Arrows well
enough yet to get certain tasks done efficiently with them.
But so far my impression is that they are great for certain
tasks and not so great for other tasks. Which doesn't really
come as a surprise. "One size fits all" doesn't seem to
exist in the real world. 

Peter