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.
(->) is often called the "function arrow" or "function type constructor", and while it does have some special syntax, there's not that much special about it. It's essentially an infix type operator. Give it two types, and it gives you the type of functions between those types.
The left arrow gets used in do notation as something similar to variable binding, in list comprehensions for the same (I'm assuming they are the same, as list comprehensions look like condensed do blocks), and in pattern guards, which have the form (p <- e). All of those constructs bind a new variable.
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!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With