To write our first arrow, we'll need the IOF type from the previous example. This time we call our meta type for IO functions IOArrow:

  data IOArrow a b = IOArrow {runIOArrow :: a -> IO b}

To make IOArrow a true Arrow, we need to implement Category and Arrow. Category describes function composition (.).

instance Category IOArrow where
  id = IOArrow return
  -- (.) = (<<<<)
  IOArrow f . IOArrow g = IOArrow $ f <=< g

instance Arrow IOArrow where
  -- arr = lift'
  arr f = IOArrow $ return . f 
  first (IOArrow f) = IOArrow $ (a, c) -> do
    x <- f a
    return (x, c)

The arr function is just lift' from earlier (using IOArrow instead of IOF). Recall that return lifts a value into a Monad and pure lifts a value into an Applicative. The arr function is to Arrow what return and pure are to Monad and Applicative, respectively.

Before we delve into the meaning of the first function and the other key Arrow operators, let's use our IOArrow function:

import Prelude hiding ((.), id)
import Control.Category
import Control.Applicative
import Control.Arrow
import Control.Monad
import System.IO

main = do
 let f = IOArrow print . 
           arr length . 
           arr words . 
           IOArrow readFile
  -- vs print . length . words . readFile
  runIOArrow f "jabberwocky.txt"

By defining arr, first, and (.) on the Category instance, we get many other operators for free. For example, the (<<<) operator defines Arrow composition. It is another name for the (.) composition function that we defined in the arrow's Category instance:

  (<<<) :: Category cat => cat b c -> cat a b -> cat a c

Instead of using (.), we could have composed our arrows with the (<<<) operator:

main = do
 let f = (IOArrow print) <<< (arr length) <<< 
           (arr words) <<< (IOArrow readFile)
  runIOArrow f "jabberwocky.txt"

The (>>>) operator is simply composition, reversed:

  (>>>) = flip (.)

For example:

main = do
let f = (IOArrow readFile) >>> 
          (arr words) >>> 
          (arr length) >>> 
          (IOArrow print)
  runIOArrow f "jabberwocky.txt"

To understand the first operator, let's tweak our arrow pipeline:

main = do
 let f = (IOArrow readFile) >>> 
           (arr words) >>>
           (arr (x -> (x,x))) >>> -– split stream in 2
           (arr length) >>> 
           (IOArrow print)
  runIOArrow f "jabberwocky.txt"
  – INVALID code  

After computing (arr words), we split the result into a 2-tuple, with both parts containing the words in the file. This won't work anymore because (arr length) expects to be fed a single value and will now be given a tuple instead.

But we can tell the (arr length) arrow to only act on the first element in the tuple:

main = do
  let f = (IOArrow readFile) >>> (arr words) >>>
      (arr (x -> (x,x))) >>>  -– split stream in 2
      (first (arr length)) >>> -- act on first tuple value
      (IOArrow print)
  runIOArrow f "jabberwocky.txt"

Now our final result is a tuple, the first part containing the word count, and the second the original words, which remained untouched. In this way, we can create "side channels" in our pipelines, which enable us to share state across arrows in a pipeline. Similarly, the second operator works on the second part of the arrow's input:

main = do
  let f = (IOArrow readFile)   >>> (arr words) >>>
      (arr (x -> (x,x)))  >>> -– split stream in 2
      (first (arr length)) >>> –- act on fst tuple value
      (second (arr head))  >>> –- act on snd tuple value
      (IOArrow print)
  runIOArrow f "jabberwocky.txt"

Now we're doing two different arrow computations on the different branches. The final operator we'll look at is (***):

main = do
  let f = (IOArrow readFile) >>> (arr words) >>> 
      (arr (x -> (x,x))) >>>
      (arr length *** arr head) >>>   
      (IOArrow print)
  runIOArrow f "jabberwocky.txt"

This operator does what we did earlier with first and second: it enables us to compute on both the first and second tuple values.

The ability of arrows to take multiple inputs enables us to build intricate pipelines with branching and merging of stream values.

Our IOArrow type:

  data IOArrow a b = IOArrow {runIOArrow :: a -> IO b}

is unnecessary because there is already the Kleisli Arrow, which generalizes IOArrow to all Monad:

-– (already defined in Control.Arrow)
data Kleisli m a b = K {runKleisli :: a -> m b}
instance Monad m => Arrow (Kleisli m) where 
  arr f = K (x -> return (f x)) 
  K f >>> K g = K (x -> f x >>= g)

Thanks to Kleisli arrows, we could have just said this:

main = do
       let f = Kleisli print . arr length . 
               arr words . Kleisli readFile
       runKleisli f "jabberwocky.txt"

All Monad have a corresponding Kleisli Arrow, but there are more instances of Arrow than of Monad. In the same way, there are more Applicative Functor than Arrow instances, and more Functor than Applicative Functor.

Despite Arrow being more generic than Monad, we left this pattern until last because it is easier to understand from the perspective of Monad. Also, Monad has been around in Haskell (early 1990s) for much longer than Arrow (early 2000s).

We can now add arrows to the list of ways of doing "effectful programming" (IO). Moreover, in the same way that we could compose different monads together into monad stacks, we can combine different arrows into stacks using transformer arrows.

Returning to the abstraction hierarchy, as the types get more powerful (from Functor to Monad) the means of composition becomes poorer!

In 1996, Swierstra and Duponcheel published an optimization to deal with the space leaks prevalent in monadic parsers. Their solution avoided the use of monads.

(S.D. Swierstra, L. Duponcheel. Deterministic, error-correcting combinator parsers, Advanced Functional Programming, Lecture Notes in Computer Science Tutorial, Vol. 1129, Springer, Berlin, 1996, pages 184–207).

John Hughes generalized their ideas, and in the process, generalized Monad to Arrow. Hughes published the first Arrow paper in 2000. It took a few more years for Arrow to become established in Haskell.

Arrows have been useful in parsers, streaming applications, and user interfaces, and in recent years they have featured prominently as an approach to functional reactive programming. (See https://wiki.haskell.org/Yampa, https://wiki.haskell.org/Netwire).