Will Yager will.yager at gmail.com
Wed Feb 15 18:03:38 UTC 2017

```Given

StateT mf <*> StateT mx

mf :: s -> m (a -> b, s)

mx :: s -> m (a, s)

We have (s :: s) in scope. We can apply mf to s no problem. Now what do we do with mx? We also need to give it (_ :: s). We could give it the same s we gave mf, but that would be wrong. It would ignore any state changes in mf.

So the correct option is to use the s value returned by mf. But there's no way to get it out of the monad. You could use the functor properties of m to get

fmap (\(s, f) -> fmap (\(s, a) -> (s, f a)) (mx s)) (mf s)

Which has type

m (m (s, b))

So you still need a monadic join to get the desired result.

The applicative instance doesn't really help as far as I can tell because it doesn't let you do anything to things of the form

x -> m y

Which is what StateT is made of.

Will

> On Feb 15, 2017, at 11:01 AM, Laurent Christophe <lachrist at vub.ac.be> wrote:
>
> Hi guys, the way `StateT` are implemented as `Applicative` have been buggling my mind for some time.
>
> instance (Functor m, Monad m) => Applicative (StateT s m) where
>     pure a = StateT \$ \ s -> return (a, s)
>     StateT mf <*> StateT mx = StateT \$ \ s -> do
>         (f, s') <- mf s
>         (x, s'') <- mx s'
>         return (f x, s'')
>
> Using dependant monadic computations, this implementation cannot be expressed in term of applicative.
> This explains why we cannot have `instance (Applicative m) => Applicative (State s m)`.
> However using real monadic style computations for implementing `<*>` buggles my mind.
> Moreover `liftA2 (<*>)` can be used to generically compose applicative functors so why monads are needed?
>
> Any inputs would be greatly appreciated!
>
> Cheers,
> Laurent
> _______________________________________________