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

[Alexander Solla]

On Oct 11, 2010, at 11:48 AM, Gregory Crosswhite wrote:

> No, but there is no point in using a formalism that adds complexity  
> without adding functionality.  Arrows are more awkward to use than  
> monads because they were intentionally designed to be less powerful  
> than monads in order to cover situations in which one could not use  
> a monad.  When your problem is solved by a monad there is no point  
> in using arrows since an arrow require you to jump through extra  
> hoops to accomplish the same goal.
>

But they do "add" functionality.  An arrow is something like a monad/ 
co-monad pair.  Half of the arrow is defined to parse input.  The  
other half is defined to process the parse tree and produce output.   
An arrow is "just" a functor from one named type to another.

> No, that is not at all the problem with arrows.  The problem with  
> arrows is that they are more restrictive than monads in two  
> respects.  First, unlike monads, in general they do not let you  
> perform an arbitrary action in response to an input.  Second, they  
> place restrictions on how you define the input arguments of the  
> arrow because you can't feed the output of one arrow into to input  
> of the next unless said input is captured in the arrows type.

They aren't more restrictive.  Just use an identity comonad for the  
input half if you want to deal with monads.  You can even make monad  
instances for arrows of this form.  The latter objection is rather the  
point of using an arrow.  "Parser -> Process", in a single construct.   
There is an analogy here.  A monad,  in general corresponds to a  
catamorphism on a functor algebra.  A co-monad corresponds to an  
anamorphism.  The compositon of an anamorphism and catamorphism is a  
hylomorphism.  A thing that unwraps and re-wraps.

I do tend to use the functor type class (or category-extras, or even  
data.category) much more than arrows, though.  It's all more-or-less  
the same.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101014/004f47f6/attachment.html