Talk:Programming:Haskell arrows/Kowey

I'm using the same pattern for monad transformers of using the talk page to jot down my notes as I attempt to understand arrows, digesting it and then regurgitating it on the module page. So the following shall be a mess. -- Kowey 12:58, 15 February 2006 (UTC)

So what?
What are they good for? What can they do easily that monads can't?


 * Ok, so from the JH paper, you can use it to avoid certain space and time leaks. The basic idea is to make certain decisions early on rather than waiting until the very end when you've done a bunch of useless work.
 * Parallel computation...

Parallelism idea
I was thinking maybe one angle of attack would be to present arrows as a means of representing computation that is done in parallel. I mean, when you've got a piece of monadic code like this x <- thingOne y <- thingTwo return $ x + y

...what's not so nice is that x and y are calculated in a sequence, which is not neccesarily what you really wanted to say. It seems from my hazy understanding of arrows so far is that what they buy you is further seperation of the sequence-plumbing so that you can write stuff which does not introduce any sequence contraints that you didn't really intend. But actually, I still don't have the slightest clue what I'm saying.

Stream processors ideas
Huh... maybe stream processors is the way to go. It seems easier to understand than the parsing stuff, and lends itself much more readily to pretty pictures. What I'm thinking is that each machine has two conveyor belts, an input belt and an output belt. Arrows give you a handy way to link machines together and do all sorts of routing stuff. Of course, I might be completely wrong here, but if I'm not, woohoo! Almost ready to write the tutorial! -- Kowey 20:02, 21 February 2006 (UTC)


 * Conveyor belts idea implemented. Now I need to understand some more arrow stuff before I can move on. -- Kowey 11:54, 22 February 2006 (UTC)