Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Uwe Schmidt]

Hi Gregory,

>   Could you explain to me why HXT uses arrows?  I have never been able
> to figure out what advantage this gives your library over monads.  Since
> your arrows in practice implement ArrowApply, they are really just
> monads anyway, so it seems to me that using arrows instead of monads
> only serves to add complexity to the library without adding any
> benefit.  Furthermore, by using arrows instead of monads people cannot
> use the many standard monad libraries out there, but have to instead
> write their own generalizations of them to arrows.
>
> Is there some benefit that your library gets out of using arrows that I
> missed which makes these costs worth it?

Hi Heinrich,

> I have the same question.
>
> It looks like the arrows in HXT are typed version of  CFilter  from
>
>     Malcolm Wallace, Colin Runciman.
>     Haskell and XML: Generic Combinators or Type-Based Translation?
>     http://www.haskell.org/HaXml/icfp99.html
>
> but it appears to me that representing them as
>
>     type Filter a b = a -> [b]
>
> allows the use of the list monad, which would highlight the similarity
> between list comprehensions and working with XML trees.

I thing, this is not a question of functionality, it's a question of style.
Of course everything in hxt could have been done with monads,
but does this also mean: Everything must have been done with monads?

We all have learned the elegant style of point free programming as
described in IFPH and Richard Birds new book gives a lot
more valuable examples of this.
When these elegant algorithms have to be generalized, e.g. to do
some IO, we have to rewrite the whole algorithms in a monadic style.
I don't like this.

Arrows are a generalisation of functions, so if you know all about working 
with functions you know (almost) all about working with arrows.
When generalizing a pure algorithm, something like "f3 . f2 . f1",
or in Unix pipe style "f1 >>> f2 >>> f3", you don't have to rewrite
the code, you just generalize function composition.
 
When constructing code, it is of course sometimes simpler to start with a 
point wise version and then refactor and rewrite it into a more compact point 
free version. The problem with arrows seems, that the arrow style forces to 
start with the point free style. And that may be the main hurdle in mind.

What we should have done in hxt, is to combine the arrows with arbitrary 
monads, at the moment the monadic arrows work with a combination of a
state and IO. The list gives us the "nondeterminism" and the exception (empty 
list). You can do a lot of things with this, but it can be generalized. And 
perhaps we'll do this in the future.

I hope this shows a bit of the motivation for taking the arrow approach,

  Uwe