Talk:Haskell/Understanding arrows/Archive 1

/Kowey
I am currently using the sub talk page /Kowey to learn about arrows and eventually dump the results on the module. Feel free to modify it, of course -- Kowey 13:12, 15 February 2006 (UTC)

The plan
Here's what I had in mind for the arrows module: while optimising monadic parser combinator libraries is very interesting in itself, it is probably too hard to think about in the very beginning, when all the reader really wants to do is understand the arrow machinery.
 * 1) We start with a very brief description of what arrows are for
 * 2) Then dive straight into the machinery, with diagrams (done)
 * 3) Show a simple implementation of arrows
 * 4) Show some simple stream processor stuff (note: i don't understand this yet)
 * 5) Explain the the S+W parser, using the arrow machinery directly! Don't bother with   - this is where shapr's tutorial comes in
 * 6) Discuss the relationship between monads and arrows.

-- Kowey 11:25, 22 February 2006 (UTC)

May I suggest introducing the syntactic sugar first, and then showing how it maps to the underlying Arrow functions? This follows the style for explaining monads: start with the sugared version and then show how the ">>=" and ">>" functions support it. I spent a long time trying to understand this business with pairs. Then I got on to the syntactic sugar and it started to make sense.

Its not made easier by the various papers that put everything into point-free form. Very clever, but much harder to follow because there are no meaningful variable names to act as signposts.

PaulJohnson 22:02, 1 July 2006 (UTC)


 * Hmm, I do think the sugar should be introduced at some point. Right now though, the way we explain monads starts with the bind operator and only mentions the sugar as the side note in the end.  That being said, the reason I did that is to insist on the underlying mechanisms (binding) because usually by the time my target audience reads the tutorial, it has already used monads some and just want to know how it works.  With arrows, it's a bit different because said audience has likely NOT used them before, so maybe introducing the sugar first would work.  (I don't actually know what the sugar does yet).  In any case, we'll have to play around with this.  I still haven't got all the way up to understanding the arrowfied S+W parser and that is my principle blocker.  -- Kowey 18:20, 6 July 2006 (UTC)

Sigh...
I should really highlight the fact that I still don't know what I'm talking about re: arrows. The module is really just what I have gleaned from arrow literature and mostly me trying to understand what's going on. So if you feel like I'm going down some pedagogical dead-end, and that the module needs to take a different tack, please be bold about it and change everything around. The point being, the structure of this text is NOT really on purpose and subject to being turned upside down. -- Kowey 16:54, 9 July 2006 (UTC)


 * Alright... I really do think I'm writing myself into a dead-end here. What I want to do is partly what Paul suggested
 * Have two arrow chapters, Haskell/Arrows and Haskell/Understanding arrows. The present chapter will become Understanding arrows
 * In the first chapter, do NOT explain arrows. Show the sugar notation, and walk the user through some exercises... the only problem is that I need a simple task that we can do with arrows (even if it's not necessarily made for arrows).  It will be like Paul said.  First the reader learns how to work with arrows without really really getting why they work, and then we show what's behind the curtain.  So any ideas for simple exercises? -- Kowey 09:41, 10 July 2006 (UTC)

metaphor obsolete
I should point out that thanks to Apfelmus's intervention, the monad chapter no longer relies on the metaphor. So we should rewrite the intro to reflect this (I think here it's kinda handy, but no need to make an allusion) -- Kowey (talk) 16:49, 16 March 2008 (UTC)

"Arrow Limitations"
While most of this article is excellent and very helpful, the section titled "Arrows aren't the answer to every question" is not very useful. While I'm sure arrows have limitations, this paragraph provides no insight into what these limitations might be. There are only nebulous mentions of research done on IRC channels and pointers to references that don't exist. While it might be useful to have a section on the limitations of arrows, I propose that for the time being this small section (and the list of names below) be removed as they add no value and seem somewhat unprofessional. I would make this change myself but I don't want to step on anybody's toes. Walkie (talk) 09:07, 8 April 2009 (UTC)


 * I'm fine with it, go ahead.
 * -- apfe&lambda;mus


 * Done, thanks. Walkie (talk) 08:29, 10 April 2009 (UTC)

"Not compiled in ghc-6.10.3"
possible fix bellow. --VladimirSorokin (talk) 12:34, 3 July 2009 (UTC)

example does not work with ghc 6.12.1
i just copied the first example from the page into a file (as per instructions) and got toyArrow.hs:4:13: parse error on input `->'

missing is {-# LANGUAGE Arrows #-}

and i have added it to the example, to make sure this works even for beginners

this

monad link doesn't make sense?
"In this tutorial, we shall present arrows from the perspective of stream processors, using the factory metaphor from the monads module as a support." -- the monad section linked to does not, in fact, mention any kind of factory metaphor AFAICT.

--21:17, 17 June 2012 (UTC)Rlpowell (discuss • contribs) 21:17, 17 June 2012 (UTC)


 * The reference is to an old version of Understanding Monads. I am going to remove it. Duplode (discuss • contribs) 00:19, 29 September 2013 (UTC)


 * Removing the mention is unfortunately only semi-helpful, since at least the first couple of sections still frequently refer back to the factory metaphor for monads. Knuton (discuss • contribs) 19:45, 1 October 2013 (UTC)

Arrows require category instance
You guys defined an instance of arrow for the parser, but if you type the code in it won't compile Why? Because (>>>) isn't a visible function for class Arrow. It's derived from being a subclass of Category, where you define (.) Since (>>>) = flip (.), this would be really trivial to fix - just write the instance of arrow, then the instance of category GallagherCommaJack 22:58, 11 March 2013 (UTC)


 * I believe that is so because the current text was written before the class  was a thing. I am reworking this chapter, and will fix it soon.--Duplode (discuss • contribs) 14:01, 14 July 2015 (UTC)


 * Now fixed.--Duplode (discuss • contribs) 19:25, 15 July 2015 (UTC)

Remove the awful factory metaphor please
I don't understand arrows enough to do this myself. I tried and tried to get this, but the factory concept is not working. I know metaphors often help, but in this case I think this is like the awful attempts at Monad metaphors. Robots and machines with conveyor belts… It's all way to concrete and multi-faceted. It generates its own system that is then hard to connect back, and we lose the thread of what we're really talking about. Backfromquadrangle (discuss • contribs) 06:02, 16 May 2014 (UTC)


 * Monads are factories, and arrows are just factories with parallel assembly lines... well, I agree wholeheartedly. I will make an attempt at reshaping this chapter, probably once Applicative is dealt with.--Duplode (discuss • contribs) 08:27, 16 May 2014 (UTC)