Arrow and Monad, two independent viewpoints to compose computations?

Question

I've reading the "The Typeclassopedia" by Brent Yorgey in Monad.Reader#13 ,and found that "the Functor hierachy" is interdependent of "the Category hierachy" as the Figure.1 shown.

And according to the author, ArrowApply == Monad, especially that the previous one is just a type class instance that can be used when

"we would like to be able to compute an arrow from intermediate results, and use this computed arrow to continue the computation. This is the power given to us by ArrowApply."

But how can we put these things together ? I mean that there are some flow control functions both in Monad and Arrow ( like if and else vs. ArrowChoice, or forM vs. ArrowLoop), and some features seem like "missing" in Monad ( (***),(|||) or first). All these are seem like that we need to make a choice between using Monad or Arrow system to construct our side effect computation flow, and will lose some features in another system.

I'm not sure what exactly your question is here, but you can see some of the connection between monads and arrows in the [`Kleisli`](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:Kleisli) and [`ArrowMonad`](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#t:ArrowMonad) newtypes. — hammar, Dec 03 '11 at 07:09
My question is : why Arrow* has so many similar things I can found in Monad ? And if ArrowApply IS Monad, why Haskell need two parallel type class hierarchy to do the same (or not ? ) things ? — snowmantw, Dec 03 '11 at 07:42

score 12 · Accepted Answer · edited Dec 03 '11 at 10:58

The answer lies in the following (all of this is from the Control.Arrow docs)

newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)
instance Monad ArrowApply a => Monad (ArrowMonad a)

The ArrowMonad newtype is the vehicle with which we define the Monad instance for ArrowApply arrows. We could have used

instance Monad ArrowApply a => Monad (a ())

but this would've caused problems with Haskell's limited type class inference (It would work with the UndecideableInstances extension, I fathom).

You can think of the Monad instance for ArrowApply arrows as translating monadic operations into equivalent arrow operations, as the source shows:

instance ArrowApply a => Monad (ArrowMonad a) where
        return x = ArrowMonad (arr (\_ -> x))
        ArrowMonad m >>= f = ArrowMonad (m >>>
                        arr (\x -> let ArrowMonad h = f x in (h, ())) >>>
                        app)

So know we know that ArrowApply is as powerful as Monad since we can implement all of the Monad operations in it. Surprisingly, the converse is also true. This is given by the Kleisli newtype as @hammar noted. Observe:

newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }

instance Monad m => Category (Kleisli m) where
        id = Kleisli return
        (Kleisli f) . (Kleisli g) = Kleisli (\b -> g b >>= f)

instance Monad m => Arrow (Kleisli m) where
        arr f = Kleisli (return . f)
        first (Kleisli f) = Kleisli (\ ~(b,d) -> f b >>= \c -> return (c,d))
        second (Kleisli f) = Kleisli (\ ~(d,b) -> f b >>= \c -> return (d,c))

instance Monad m => ArrowApply (Kleisli m) where
        app = Kleisli (\(Kleisli f, x) -> f x)

instance Monad m => ArrowChoice (Kleisli m) where
    left f = f +++ arr id
    right f = arr id +++ f
    f +++ g = (f >>> arr Left) ||| (g >>> arr Right)
    Kleisli f ||| Kleisli g = Kleisli (either f g)

The previous gives implementations for all of the usual arrow operations using monad operations. (***) is not mentioned since it has a default implementation usin first and second:

f *** g = first f >>> second g

So now we know how to implement arrow (Arrow, ArrowChoice, ArrowApply) operations using Monad operations.

To answer your question about why we have both Monad and Arrow if they turn out to be equivalent:

The less powerful arrows are useful when we do not need the full power of a monad, just like applicative functors can be useful. And even though ArrowApply and Monad are equivalent, an Arrow or ArrowChoice without app is something that is not representable in the Monad hierarchy. Vice versa, an Applicative is not representable in the arrow hierarchy. This is because ap comes "first" in the monad hierarchy and "last" in the arrow hierarchy.

The main semantic difference between the monad and arrow worlds is that arrows capture a transformation (arr b c means we produce a c from a b), while monads capture an operation (monad a produces an a). This difference is reflected well in the Kleisli and ArrowMonad newtypes:

newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }
newtype ArrowApply a => ArrowMonad a b = ArrowMonad (a () b)

In Kleisli we have to add the source type a, and in ArrowMonad we set it to ().

I hope this satisfies you!

Thank you! I'll spend sometime to study those types you mentioned in the answer later (it's 23:00 in my region :) ) . — snowmantw, Dec 03 '11 at 15:03
Nice! Definitely some stuff to think about as we continue to imagine what Haskell Prime base libraries should look like. — Dan Burton, Dec 04 '11 at 00:21
The `ap` in the monad hierarchy doesn't do the same as the `app` of `ArrowApply`, as in run code produced by the previous operation. In both the monad hierarchy and the Arrow hierarchy this comes at that Monad==ArrowApply point, with `>>=` in monads, which allows `produceMonadicValue >>= id` and `app` in arrows which allows `produceArrowValue >>> app`. Arrow can already do the equivalent of Applicative's `ap` or `(<*>)`: If we have an arrow `A` and `makef :: A () (x->y)` and `makex :: A () x` we can do `makef &&& makex >>> pure (uncurry ($))` which does the same as `makef' <*> makex'` would. — AndrewC, Feb 23 '14 at 21:21
`instance ArrowApply a => Monad (a ())` doesn't need `UndecidableInstances`, it only needs `FlexibleInstances` — ThePiercingPrince, Mar 22 '14 at 14:21

Arrow and Monad, two independent viewpoints to compose computations?

1 Answers1