After listening to the latest Magic
Read-along episode "You should watch
this" (which you should go listen to
now) I got caught up thinking about Brian's idea of an Endomorphism version of
Kleisli composition for use with
Redux, it's actually a very similar
model to what I'm using in my event framework for
event listeners so I figured I'd try to formalize the pattern and recognize
some of the concepts involved. They talk about the idea of a
Redux-reducer, which is usually of type `s -> Action -> s`

, it takes a state
and an action and returns a new state. He then re-arranged the arguments to
`Action -> s -> s`

. He then recognized this as `Action -> Endo s`

(an
Endo-morphism is just any function from one type to itself: `a -> a`

). He
would take his list of reducers and partially apply them with the `Action`

,
yielding a list of type `Endo s`

where `s`

is the state object the reducer
operates over. At this point we can use the Monoid instance `Endo`

has defined,
so we foldmap with Endo to combine the list of reducers into a sort of pipeline
where each function feeds into the next; the Endo instance of Monoid is just
function composition over functions which return the same type as their input.

This cleans up the interface of the reducers a fair amount, but what about an
alternate kind of `Endo`

which uses Kleisli composition instead of normal
function composition? Kleisli
composition
often referenced as (>=>); takes two functions which return monads and
composes them together using the underlying bind/flatmap of the Monad. The type
of Kleisli composition is:
`(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c`

. If we could define
a nice Endo-style monoid over this type then we could compose reducers like we
did above, but also allow the functions to perform monadic effects (which is a
bad idea in Redux, but there are other times this would be useful, imagine
running a user through a pipeline of transformations which interact with a
database or do some error handling). We can easily define this instance like
so:

```
import Control.Monad
newtype KEndo m a = KEndo
{ getKEndo :: (a -> m a) }
instance Monad m => Monoid (KEndo m a) where
mempty = KEndo return
(KEndo a) `mappend` (KEndo b) = KEndo (a >=> b)
```

This is great, now if we have a list of functions of some type `[User -> Writer Error User]`

or something we can
use foldmap to combine them into a single function! It works like this:

```
actions :: [User -> Writer Error User]
actions = [...]
pipeline :: User -> Writer Error User
pipeline = getKEndo . foldMap KEndo $ actions
```

The whole Kleisli Endo thing is a cool idea; but this thing has actually been
done before! It's actually the same as the
`StateT`

state monad transformer from mtl; let's see how we can make the comparison. A
generic Endo is of type `s -> s`

, this is isomorphic to `s -> ((), s)`

, aka
`State s ()`

. The trick is that the Kleisli Endo (`s -> m s`

or by isomorphism
`s -> m ((), s)`

) can actually be generalized over the `()`

to `s -> m (a, s)`

which incidentally matches `runStateT :: StateT s m a -> s -> m (a, s)`

from
mtl!

So basically KEndo is isomorphic to StateT, but we'd still like a monoid instance for it, Gabriel shows a monoid over the IO monad in "Applied category theory and abstract algebra", the Monoid he shows actually generalizes to any monad as this instance:

```
instance (Monad m, Monoid a) => Monoid (m a) where
mempty = return mempty
ma `mappend` mb = do
a <- ma
b <- mb
return (a `mappend` b)
```

So that means we can use this instance for StateT (which is a monad). Since
`()`

is a trivial monoid (where every mappend just returns `()`

) the simple
case is `State s ()`

which was our `KEndo`

of `s -> ((), s)`

but now we have
the Monoid instance, which behaves the same as the `KEndo`

instance, so we
don't need `KEndo`

anymore. If we want to allow arbitrary effects we use the
Transformer version: `StateT s m ()`

where `m`

is a monad containing any
additional effects we want. In addition to being able to add additional effects
we also gain the ability to aggregate information as a monoid! If you decided
you wanted your reducers to also aggregate some form of information, then
they'd be: `Monoid a => Action -> s -> (a, s)`

, which is `Action -> State s a`

,
and if `a`

is a monoid, then the monoid instance of `State`

acts like Endo, but
also aggregates the 'a's along the way!

Lastly we recognize that in the case of the Redux Reducers, if we have a whole
list of reducers: `Action -> State s ()`

then we can rephrase it as the ReaderT
Monad: `ReaderT Action (State s) ()`

, which maintains all of the nice monoids
we've set up so far, and becomes even more composable!