[Haskell-cafe] Re: request for code review

Pete Chown 1 at 234.cx
Tue Mar 14 08:46:23 EST 2006


Shannon -jj Behrens wrote:

> I'm only using |> as a replacement
> for $ because I find it more readable to read left to right than right
> to left.

You can see this in two different ways, I think.  Imagine the following:

(+1) (*2) 3

This is not legal Haskell because it gets parsed as:

((+1) (*2)) 3

To avoid this problem, we can add our own brackets:

(+1) ((*2) 3)

Speaking loosely, $ is an alternative to the brackets, so we can also write:

(+1) $ (*2) 3

We get the answer 7 whether we use brackets or $.  If $ is going to be 
an alternative to brackets, we would be a bit surprised if the 
evaluation order changed.  At the same time, it's true that if you think 
of this as a Unix pipe, the evaluation order is the wrong way round.  We 
are evaluating right to left.

Arrows are meant to be like Unix pipes.  The whole idea is that you 
build up pipelines (and networks) of arrows.  Usefully for you, 
functions are a kind of arrow, so you get the arrow operators 
automatically.  As expected

((+1) >>> (*2)) 3

gives 8 and not 7.

> Arrows looks like a replacement for monads.  Are you saying
> I should drop my use of the State monad?  If so, why?  I like the
> readability of the do syntax.

Okay, now it's my turn to ask a question. :-) I've read about arrows, 
and while I think I see what they do, I'm not sure why they are seen as 
so special that they even get new syntax.  This question of Shannon's is 
exactly the point I struggle with.  I can see that the arrow operators 
might be useful with functions, but are they useful for other things 
too?  For example, as monads are one kind of arrow, I thought I would 
make some of the I/O functions into arrows and see what happened.  The 
result was pretty much the same as using the monad, except slightly less 
convenient.

I've been trying to use the arrow interface to HXT, but I don't see why 
it works better with arrows rather than functions.  The arrows all do 
various transformations on the XML, but isn't that the idea of a 
function?  Couldn't processTopDown, for example, be a function that maps 
an input XML tree to an output one, and takes a lambda expression which 
is to be applied to each node?

Thanks,
Pete



More information about the Haskell-Cafe mailing list