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.
The answer lies in the following (all of this is from the Control.Arrow docs)
The
ArrowMonadnewtype is the vehicle with which we define theMonadinstance forArrowApplyarrows. We could have usedbut this would’ve caused problems with Haskell’s limited type class inference (It would work with the
UndecideableInstancesextension, I fathom).You can think of the
Monadinstance forArrowApplyarrows as translating monadic operations into equivalent arrow operations, as the source shows:So know we know that
ArrowApplyis as powerful asMonadsince we can implement all of theMonadoperations in it. Surprisingly, the converse is also true. This is given by theKleislinewtype as @hammar noted. Observe:The previous gives implementations for all of the usual arrow operations using monad operations.
(***)is not mentioned since it has a default implementation usinfirstandsecond:So now we know how to implement arrow (
Arrow,ArrowChoice,ArrowApply) operations using Monad operations.To answer your question about why we have both
MonadandArrowif 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
ArrowApplyandMonadare equivalent, anArroworArrowChoicewithoutappis something that is not representable in theMonadhierarchy. Vice versa, anApplicativeis not representable in the arrow hierarchy.This is because
apcomes “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 cmeans we produce acfrom ab), while monads capture an operation (monad aproduces ana). This difference is reflected well in theKleisliandArrowMonadnewtypes:In
Kleisliwe have to add the source typea, and inArrowMonadwe set it to().I hope this satisfies you!