haskellmonadstypeclassarrow-abstraction

Arrow and Monad, two independent viewpoints to compose computations?


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.

Figure.1

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.


Solution

  • 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!