The advantage of arrows over functions

Question

What is the advantage of arrows over regular functions in haskell. What they can do, functions cannot. Functions can display structures using fmap.

Answer 1

In the wider picture, the arrows go from Hask to other categories that need to be explored. The Kleisli category is probably best known for the Haskellers and then Cokleisli . These are the natural "extensions" of Hask : add an endofunctor around the result or argument, then you will get a category again if

• Kleisli : the functor is a monad, so id ≅ return :: a -> ma

   (.) ≅ (<=<) :: (b->mc) -> (a->mb) -> a->mc 

• CoKleisli : the functor is comonad, therefore id ≅ coreturn :: ma -> a and

   (.) :: (m b->c) -> (m a->b) -> m a->c 

(For this you don't need Arrow yet, but only Category . But general categories are not very interesting, you usually want monoidal or even Cartesian closed categories, which means that Arrow roughly aimed at.)

But there are many other categories . Most do not have much to do with Hask and cannot be expressed by the standard Arrow class, mainly because objects have special properties that do not correspond to each Haskell type. In fact, if you add the ability to restrain object types, the possibilities immediately become much wider . But even if you stay with the standard classes, perhaps even just in -> , the exact composition style, natural with arrows, often comes out very beautifully, succinctly and opens up new ways to think about transformations.

Answer 2

Functions are just an instance of arrows, he asks: "Why use monads instead of just Maybe ."

All that you can do with the arrows, of course, can be done using functions, since an Arrow (->) instance can talk about only one small part of the functions, namely, that in a class like Arrow . However, arrows have more instances than just simple functions, so we can use ssame functions to work with more complex types.

The arrows are good, because they can have much more structure than just a function, when going around only with fmap we have no way to accumulate effects, more expressive than monads! Consider the Claysley arrow,

 newtype Kleisli mab = Kleisli {runKleisli :: a -> mb} 

This forms an arrow when m is a monad. Thus, each Monad forms an arrow, and therefore we can create monadic calculations by smoothly composing a -> mb and do all kinds of useful things like this. Some XML libraries use arrows to abstract over functions from an element to its subitems and use this to move around a document. Other parsers use arrows (their original purpose), although currently this seems to drop out due to Applicative rejection.

What you hopefully noticed is that arrows are more general, when we just talk about arrows, we avoid duplicating all the code we need to write in order to do something with our analyzers, xml scrapers and monadic functions

Just like choosing Monad over Maybe , we lose some power, since we can no longer create specific instructions, but we return a more general code.