Talk:Haskell/Understanding arrows

Ross Paterson
Ross Paterson has kindly given us permission to use material from the Haskell arrows page, as well as the parts of the GHC User's guide on arrows. But be careful! His Arrows and computation book chapter belongs to his publisher, so we'd better not use that. -- Kowey 11:40, 15 February 2006 (UTC)

Shae Erisson
In #haskell, Shae Erisson has helpfully given us permission to use material from the TMRWiki introduction to arrows. Thanks again, shapr! -- Kowey 14:50, 20 February 2006 (UTC)


 * The link is now dead. I only managed to find the original text with the Wayback Machine.--Duplode (discuss • contribs) 06:54, 15 July 2015 (UTC)

Parser nitpicking - is buggy
About the definition of  for arrow parsers: if  's dynamic component doesn't check whether the first character of input is correct, relying on that having been done by the static component, then, in case of , who's going to invoke the static component of the second character parser? The definition of  shown in the section certainly doesn't do it, which results in   accepting   followed by any character.

Either the contract for a parser should require that its dynamic component rejects all invalid input (i.e. is a validating parser), or  should invoke the static component of its right operand. --Alexey Feldgendler (talk) 15:53, 15 March 2009 (UTC)


 * You're probably right. In any case, the exact details are in the D&P paper.
 * -- apfe&lambda;mus 09:16, 16 March 2009 (UTC)


 * If I'm right, then the code in this article needs to be fixed. :-) --X-Man (talk) 19:22, 19 March 2009 (UTC)


 * Certainly. :-) I'd like to make sure, though. I'm not familiar with the details myself, could you have a look at the Swierstra and Duponchel's paper for a correct implementation?
 * -- apfe&lambda;mus 07:47, 21 March 2009 (UTC)


 * Looked at the paper (BTW, shouldn't it be referenced from the article?) and found the same problem in D&P's definition of  . In their notation,   will accept   followed by any character. I'm confused now. It's probably something obvious that I'm overlooking, but to me it looks like the paper contains the same glaring bug. --X-Man (talk) 04:53, 22 March 2009 (UTC)


 * I've had a look at the paper but it doesn't mention arrows at all, does it? IIRC, there was a successor paper that does, though. Could you dig it up and have a look?
 * In any case, the irony is that the parser combinators presented in the paper you mentioned are an instance of Haskell/Applicative Functors.
 * -- apfe&lambda;mus 20:53, 23 March 2009 (UTC)


 * Using arrows for parsers was John Hughes' idea. Duponcheel writes in his blog: One of John Hughes motivations for introducing the Arrow model in Haskell was a class of error correcting parsers (developed by Doaitse Swierstra and Luc Duponcheel) that could be modelled using Arrows, but not using Monads (cfr. afp-arrows). However, if there was a mistake in the original parser paper that didn't mention arrows, it could just as well have been carried over to later papers. To me it seems like the parsers in have a bug, even though they aren't expressed as arrows. What do you think about it? /me is in terrible need of one more sensible person to confirm I'm not delusional. --X-Man (talk) 10:49, 28 March 2009 (UTC)


 * I've had a closer look now. The main definition  for sequencing the dynamic parsers is on page 11 and it indeed does not check for errors. This can be used to produce a bug as you showed. In fact,   alone will never fail which would be a bug already. However, the choice combinator   does check for errors.
 * But note that the goal of the paper is to include automatic error correction and accepting any input would be the right behavior in this case. So, the important and different question is whether there is a bug in the final version of the parsers on page 16.
 * In other words, the point is that the definition of the dynamic parsers in the paper is quite different from the one in the wikibook. Even the version from page 11 includes an extra  argument which the wikibook version doesn't have. So, the two aren't really comparable.
 * But what to do for the wikibook? (See below)
 * -- apfe&lambda;mus 09:36, 2 April 2009 (UTC)


 * What to do?
 * The full D&P stuff is probably too complicated to be included here. Also, parsers are best viewed as applicative functors anyway. But describing one of the main motivation for arrows would be nice, so a dumbed-down version similar to the present one would be great to have. So, it would be best if someone could turn it into something that actually works.
 * -- apfe&lambda;mus 09:36, 2 April 2009 (UTC)


 * I believe there might be no bug. I'm revising the texts using Hughes' paper (Generalising Monads to Arrows) as a reference - the simplified parser used here actually comes from there. It boils down to:
 * If you have, and feed it  ,   is the second character, and so the static test of   is not supposed to be invoked.
 * The static tests are only actually carried out by the alternative/ combinators, and so even though there is no static test for characters beyond the first there would still be noticeable gains (i.e. potentially skipping a lot of alternatives).
 * Finally, and this is the part I'm not 100% sure of, it seems to be implied by both Hughes and S&D that the symbol parsers are really just meant to parse a single character. If you want to write a word parser you'd use a different char parser for any characters beyond the first − a parser with a dynamic part that actually does something.
 * So, what is to be done? Preliminarily, I don't think the exercises are helpful in their current form, so I am removing them. Also, the justification for why the dynamic parser must be changed into something more meaningful. I will try to certify that I'm actually making sense with this interpretation.
 * Duplode (discuss • contribs) 21:57, 15 July 2015 (UTC)

2015-07-15 reorganisation
The reorganisation of this chapter has finally begun. Last revision before it and the corresponding solutions page  .--Duplode (discuss • contribs) 01:48, 15 July 2015 (UTC)

First half (pocket guide)
The first half of the chapter was just rewritten - only the pretty pictures and part of the exercises remain. The old version had two issues: it relied on the problematic factory metaphor (a holdout from an old version of Understanding monads) and it focused too much on the machinery, offering very little insight on what is the point of. I tried to go in the opposite direction: a bird's eye overview, focusing on the key concepts. The pace faster than the usual for me, and that is intentional: operationally, arrows are different enough from monads etc. that you could easily write a dozen pages of introduction - and it wouldn't help readers at all. The obvious consequence is that Haskell/Arrow tutorial is even more important now. I will update the lead text of the tutorial to reflect that. There are still several missing things in the first half alone:


 * The lead of the deprecated Haskell/Arrows says "[arrows] allow notions of computation that may be partially static (independent of the input) or may take multiple inputs", paraphrasing a passage in Patterson's Arrows and Computations. While the discussion in the "Arrow glides" section covers the "partially static" part well enough, the text does not mention the "may take multiple inputs" bit. It might be good to squeeze that into the text in a meaningful way. (However, perhaps there is nothing mysterious about those "multiple inputs". Though I only read the relevant passages in Patterson's very quickly while writing this, the reference is to "map transformers" and data parallelism through arrow computations, and the instance given for it is quite ziplist-like).


 * It would be great to pick a concrete use case in an actual arrowised library and mention it en passant. (By the way, the examples section at the end also needs some cleanup.)


 * More exercises are desirable - ideally, some that tie in with the tutorial.


 * In "An Arrow can multitask", when talking about the tricks with pairs I wanted to draw parallels with currying/uncurrying/partial application, and also with the relation between the applicative and monoidal presentations of . I couldn't figure out how to do that without it being horribly confusing though.


 * More images would be good. I will try to make a diagram for that snippet of non-proc arrow code in the tutorial. Pretty pictures for the ArrowChoice combinators would be cool, though I guess they won't be in the same style of the existing ones.


 * Speaking of proc-notation, I have removed the section on it as it is covered well enough by the tutorial. Only a very complete and systematic presentation might be worth the trouble, and even then probably not.

I am now going to review the second part. It has a few problems of its own, but I don't think it needs a full rewrite. --Duplode (discuss • contribs) 04:16, 15 July 2015 (UTC)

Second half (S+D/Hughes parser)
Second part review done. I believe this chapter is now roughly on par with the rest of the book up to this point in terms of readability and consistency. Further improvements for the future include:


 * I didn't bother very much with copyediting and phrasing improvements in the second part.


 * We do not show the static parsers actually being used, except for a limp footnote after the implementation of  that I added as an afterthought. That will (hopefully) be solved soon: the issue is that showing that implies showing the   implementation, which implies having introduced   in the first part of the chapter, and I don't want to do that while there is not a discussion of   somewhere else. I plan to return here to fix that once the   issue is dealt with.


 * It would be good to have an exercise asking for a working parser for a range of characters, or even a word. That, however, would only become a sensible addition once  is covered (see item above). Also, the exercise would have to account the "possible bug" discussed a few threads above, which I worked around through the only reasonable guess I could think of (see the thread above for details).


 * We could also discuss the  example from the tutorial from a more conceptual point of view. For background reading,   is very close to the automaton example in Patterson's Arrows and computation.

--Duplode (discuss • contribs) 23:45, 15 July 2015 (UTC)