Various concepts follow here, which can be seen as concrete examples covered by the arrow concept. Not all of them provide links to Haskell-related materials: some of them are here only to give a self-contained material (e.g. section [[#Automaton]] gives links only to the finite state concept itself.).

Various concepts follow here, which can be seen as concrete examples covered by the arrow concept. Not all of them provide links to Haskell-related materials: some of them are here only to give a self-contained material (e.g. section [[#Automaton]] gives links only to the finite state concept itself.).

+

+

=== Practice ===

+

+

Reasons, when it may be worth of solving a specific problem with arrows (instead of [[monad]]s) can be read in

+

[http://caml.inria.fr/pub/ml-archives/caml-list/2000/08/3c42f0fad3b3ecaca4f6043af65f6315.en.html a message from Daan Leijen].

+

But Leijen's post is rather old (2000). Arrows are now significantly easier to understand and use than they were back then. Eg, his example might be rewritten

+

test = proc _ -> do

+

question <- ask -< "what is the question ?"

+

answer <- ask -< question

+

returnA -< ("the answer to '" ++ question ++ "' is " ++ answer)

+

(or something vaguely like that).

=== Function ===

=== Function ===

−

Arow operations <hask>arr</hask> and <hask>>>></hask> are rather straightforward. For implementing <hask>first</hask> and related concepts, see [[Prelude extensions#Tuples]].

+

Arrow operations <hask>arr</hask> and <hask>>>></hask> are rather straightforward. For implementing <hask>first</hask> and related concepts, see [[Prelude extensions#Tuples]].

=== Parser ===

=== Parser ===

−

The reasons why the arrow concept can solve important questions when designing a parser library are explained in [http://www.haskell.org/arrows/biblio.html Generalising Monads to Arrows] written by [http://www.cs.chalmers.se/~rjmh/ John Hughes].

+

The reasons why the arrow concept can solve important questions when designing a parser library are explained in [http://www.haskell.org/arrows/biblio.html Generalising Monads to Arrows] written by [http://www.cse.chalmers.se/~rjmh/ John Hughes].

A good example of the mentioned arrow parsers can be seen in [http://www.soi.city.ac.uk/~ross/papers/notation.html A New Notation for Arrows] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson]: figure 2, 4, 6 (page 3, 5, 6):

A good example of the mentioned arrow parsers can be seen in [http://www.soi.city.ac.uk/~ross/papers/notation.html A New Notation for Arrows] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson]: figure 2, 4, 6 (page 3, 5, 6):

The idea of borrowing this image from mathematical analysis comes from another topic: the version control systems article [http://sourcefrog.net/weblog/software/vc/derivatives.html Integrals and derivatives] written by Martin Pool uses a similar image.

The idea of borrowing this image from mathematical analysis comes from another topic: the version control systems article [http://sourcefrog.net/weblog/software/vc/derivatives.html Integrals and derivatives] written by Martin Pool uses a similar image.

written by [http://www.cse.ogi.edu/~magnus/ Magnus Carlsson] (page 9) mentions that computation (e.g. state) is threaded through the operands of <hask>&&&</hask> operation.

+

written by [http://www.carlssonia.org/ Magnus Carlsson] (page 9) mentions that computation (e.g. state) is threaded through the operands of <hask>&&&</hask> operation.

I mean, even the mere definition of <hask>&&&</hask> operation

I mean, even the mere definition of <hask>&&&</hask> operation

<haskell>

<haskell>

p &&& q = arr dup >>> first p >>> second q

p &&& q = arr dup >>> first p >>> second q

</haskell>

</haskell>

−

shows that the order of the computation (the side effects) is important when using <hask>&&&</hask>, and this can be exemplified very well with parser arrows. See an example found in [http://www.cs.helsinki.fi/u/ekarttun/PArrows/ PArrows] written by [http://www.haskell.org/tmrwiki/EinarKarttunen Einar Karttunen] (see module <hask>Text.ParserCombinators.PArrow.Combinator</hask>):

+

shows that the order of the computation (the side effects) is important when using <hask>&&&</hask>, and this can be exemplified very well with parser arrows. See an example found in [http://hackage.haskell.org/package/PArrows PArrows] written by Einar Karttunen (see module <hask>Text.ParserCombinators.PArrow.Combinator</hask>):

The picture illustrating <hask>***</hask> in [http://en.wikibooks.org/wiki/Programming:Haskell_arrows#.2A.2A.2A Programming:Haskell_arrows] article of Wikibooks suggests exactly such a view: order of side effects can be unimportant at some arrow instances, and the symmetry of the figure reflects this. In generally, however, the figure should use a notation for threading through side effects in a sequence.

+

The picture illustrating <hask>***</hask> in [http://en.wikibooks.org/wiki/Haskell/Understanding_arrows#.2A.2A.2A Haskell/Understanding arrows] article of Wikibooks suggests exactly such a view: order of side effects can be unimportant at some arrow instances, and the symmetry of the figure reflects this. In generally, however, the figure should use a notation for threading through side effects in a sequence.

=== Stream processor ===

=== Stream processor ===

Line 96:

Line 110:

Arrows are useful also to grasp the concept of stream processors. See details in

Arrows are useful also to grasp the concept of stream processors. See details in

* [http://citeseer.ist.psu.edu/hudak89expressiveness.html On the Expressiveness of Purely Functional I/O Systems] written by Paul Hudak and Raman S. Sundaresh.

+

* [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.695 On the Expressiveness of Purely Functional I/O Systems] written by Paul Hudak and Raman S. Sundaresh.

−

* [http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/ Fudgets] written by [http://www.cs.chalmers.se/~hallgren/ Thomas Hallgren] and [http://www.cs.chalmers.se/~magnus/ Magnus Carlsson]. See also [http://www.cse.ogi.edu/PacSoft/seminar/magnus_abstract.html Arrows for Fudgets] written by [http://www.cse.ogi.edu/~magnus/ Magnus Carlsson], mentioning how these two concepts relate to each other.

+

* [http://www.altocumulus.org/Fudgets/ Fudgets] written by [http://www.altocumulus.org/~hallgren/ Thomas Hallgren] and [http://www.carlssonia.org/ Magnus Carlsson]. See also [http://www.carlssonia.org/ogi/ProdArrows/ Arrows for Fudgets] written by [http://www.carlssonia.org/ Magnus Carlsson], mentioning how these two concepts relate to each other.

* [http://kevin.atkinson.dhs.org/fg/doc/FG.html FG]

* [http://kevin.atkinson.dhs.org/fg/doc/FG.html FG]

* [[Phooey]]

* [[Phooey]]

+

* [[Grapefruit]]

==== Dataflow languages ====

==== Dataflow languages ====

Line 110:

Line 125:

[http://www.soi.city.ac.uk/~ross/papers/fop.html Arrows and Computation] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson] mentions how to mimic dataflow programming in (lazy) functional languages. See more on Lucid's own HaskellWiki page: [[Lucid]].

[http://www.soi.city.ac.uk/~ross/papers/fop.html Arrows and Computation] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson] mentions how to mimic dataflow programming in (lazy) functional languages. See more on Lucid's own HaskellWiki page: [[Lucid]].

−

== Automaton ==

+

=== Automaton ===

To see what the concept itself means, see the Wikipedia articles [http://en.wikipedia.org/wiki/Finite_state_machine Finite state machine] and also [http://en.wikipedia.org/wiki/Automata_theory Automata theory].

To see what the concept itself means, see the Wikipedia articles [http://en.wikipedia.org/wiki/Finite_state_machine Finite state machine] and also [http://en.wikipedia.org/wiki/Automata_theory Automata theory].

Line 116:

Line 131:

How these concepts can be implemented using the concept of arrow, can be found in the introductory articles on arrows mentioned above.

How these concepts can be implemented using the concept of arrow, can be found in the introductory articles on arrows mentioned above.

−

== External links ==

+

=== Haskell XML Toolbox ===

+

[[HXT]] is an example of a real application using Arrows

−

* [http://www.haskell.org/arrows/biblio.html Generalising Monads to Arrows] written by [http://www.cs.chalmers.se/~rjmh/ John Hughes].

+

== External links ==

−

* [http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf Programming with Arrows], also written by John Hughes. A more recent paper on arrows, and also a very didactic one, introducing the arrow subclasses with detailed examples and rich explanations on the motivations of each decision.

+

* [http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf ''Programming with Arrows''] - A tutorial introduction to arrows and arrow notation. Very didactic, introducing the arrow subclasses with detailed examples and rich explanations on the motivations of each decision.

−

* [http://www.haskell.org/arrows/index.html Arrows: A General Interface to Computation] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson].

+

* [http://www.haskell.org/arrows/ Arrows: A General Interface to Computation] written by [http://www.soi.city.ac.uk/%7Eross/ Ross Paterson].

* [http://www.haskell.org/arrows/biblio.html ''Generalising Monads to Arrows'', and other papers]

−

* [http://www.haskell.org/tmrwiki/ArrowsIntroduction ArrowsIntroduction] written by [http://www.scannedinavian.com/~shae/blog/index.html Shae Erisson] and published in [http://www.haskell.org/tmrwiki/IssueFour The Monad.Reader IssueFour].

+

* [http://www.carlssonia.org/ogi/ProdArrows/ ProdArrows -- Arrows for Fudgets] is also a good general material on the arrow concept (and also good for seeing, how arrows can be used to implement stream processors and Fudgets). It is written by [http://www.carlssonia.org/ Magnus Carlsson].

−

* [http://www.cse.ogi.edu/~magnus/ProdArrows/ ProdArrows -- Arrows for Fudgets] is also a good general material on the arrow concept (and also good for seeing, how arrows can be used to implement stream processors and Fudgets). It is written by [http://www.cse.ogi.edu/~magnus/ Magnus Carlsson].

+

* [http://en.wikibooks.org/wiki/Haskell/Arrows Haskell/Arrows] on Wikibooks, followed by [http://en.wikibooks.org/wiki/Haskell/Understanding_arrows Understanding arrows], which uses a factory/conveyor belt metaphor for arrows. We know this image for [[monad]]s, but it is modified here for arrows, too.

* [http://en.wikibooks.org/wiki/Haskell/Arrows Haskell/Arrows] on Wikibooks, followed by [http://en.wikibooks.org/wiki/Haskell/Understanding_arrows Understanding arrows], which uses a factory/conveyor belt metaphor for arrows. We know this image for [[monad]]s, but it is modified here for arrows, too.

Various concepts follow here, which can be seen as concrete examples covered by the arrow concept. Not all of them provide links to Haskell-related materials: some of them are here only to give a self-contained material (e.g. section #Automaton gives links only to the finite state concept itself.).

Reasons, when it may be worth of solving a specific problem with arrows (instead of monads) can be read in
a message from Daan Leijen.
But Leijen's post is rather old (2000). Arrows are now significantly easier to understand and use than they were back then. Eg, his example might be rewritten

The funny thing which took a long time for me to understand arrow parsers is a sort of differential approach -- in contrast to the well-known parser approaches. (I mean, in some way well-known parsers are of differential approach too, in the sense that they manage state transitions where the states are remainder streams -- but here I mean being differential in another sense: arrow parsers seem to me differential in the way how they consume and produce values -- their input and output.)

The idea of borrowing this image from mathematical analysis comes from another topic: the version control systems article Integrals and derivatives written by Martin Pool uses a similar image.

written by Magnus Carlsson (page 9) mentions that computation (e.g. state) is threaded through the operands of

&&&

operation.
I mean, even the mere definition of

&&&

operation

p &&& q = arr dup >>> first p >>> second q

shows that the order of the computation (the side effects) is important when using

&&&

, and this can be exemplified very well with parser arrows. See an example found in PArrows written by Einar Karttunen (see module

Text.ParserCombinators.PArrow.Combinator

):

-- | Match zero or more occurrences of the given parser.
many :: MD i o -> MD i [o]
many = MStar
-- | Match one or more occurrences of the given parser.
many1 :: MD i o -> MD i [o]
many1 x =(x &&& MStar x)>>> pure (\(b,bs)->(b:bs))

The definition of

between

parser combinator can show another example for the importance of the order in which the computation (e.g. the side effects) take place using

&&&

operation:

between :: MD i t -> MD t close -> MD t o -> MD i o
between open close real = open >>>(real &&& close)>>^fst

operation can be important. But let us mention also a counterexample, e.g. nondeterministic functions arrows, or more generally, the various implementations of binary relation arrows -- there is no such sequencing of effect orders. Now let us see this fact on the mere mathematical concept of binary relations (not minding how it implemented):

(ρ

&&&

(ρ

|||

The picture illustrating

***

in Haskell/Understanding arrows article of Wikibooks suggests exactly such a view: order of side effects can be unimportant at some arrow instances, and the symmetry of the figure reflects this. In generally, however, the figure should use a notation for threading through side effects in a sequence.

Programming with Arrows - A tutorial introduction to arrows and arrow notation. Very didactic, introducing the arrow subclasses with detailed examples and rich explanations on the motivations of each decision.