Understanding State Monad

I have tried to understand, how the bind function (>>=) for the State monad is defined, for some time now.

I have read several explanations among others Learn You a Haskell, which has great explanations, but in this case it wasn't enough. I have also looked at Three Useful Monads which tries to visualize difficult concepts in Haskell. Finally I read Real World Haskell and maybe I get it now. I'm not sure but maybe.

Bind is defined as follows.

(>>=) :: State s a -> (a -> State s b) -> State s b

First you need to understand that State s a is really a state transformer and not regular state. State s a type is defined as follows.

State s a :: s -> (a, s)

In other words the state transformer is a function that takes one state transformer and returns a new state transformer and a result of type a.

So the bind function above really takes one state transformer (lets call it trans1) and a function (lets call it makeTrans) that takes a result from trans1 (lets call it res1) and creates a new state transformer (lets call it trans2). The resulting state transformer should be a binding of trans1 and trans2 as a single state transformer trans3.

If we call the initial state s0, the intermediate state s1 (after trans1) and the resulting state s2, the new state transformer should transform between s0 and s2 and give the result from trans2 i.e. s0 -> (res2, s2).

(>>=) step1 makeStep = \s0 -> (res2, s2) 
	where
      (res1, s1) = trans1 s0
      trans2      = makeTrans res1
      (res2, s2) = trans2 s1 

This definition can be written as it is defined in the standard library.

(>>=) m k = \s -> let (a, s') = m s in (k a) s'

I thought it was easier if I could visualize this as boxes.

$$
\begin{svg}






















trans1

s0





trans2

s1
(res2, s2)





makeTrans

trans3








res1


"creates"



\end{svg}\includegraphics[width=32px]{myfig}
$$

Motivations for State Monad and monads in general

I have also had a hard time to understand what's the big deal about state monads.

This is actually really well explained in Tasteful stateful computations(LYaH), but I will give my angle anyhow.

Consider two stateful computations (push and pop) not using the state monad (from LYaH).

type Stack = [Int]

pop :: Stack -> (Int,Stack)
pop (x:xs) = (x,xs)

push :: Int -> Stack -> ((),Stack)
push a xs = ((),a:xs)

The definitions of push and pop are very clear and understandable when the state is explicitely stated as input and output parameters.

The problem arise when you want to compose functions several of these stateful computations in a single stateful computation.

stackManip :: Stack -> (Int, Stack)
stackManip stack = let
    ((),newStack1) = push 3 stack
    (a ,newStack2) = pop newStack1
    in pop newStack2

Because stateful computations are ordered the intermediate state must explicitely stated in each step which becomes tedius. This is where the State monad comes in.

The state monad allows a state to be manipulated without explicitely naming each state in a state transformer.

When using state monad the stateful computations above is defined as state transformers.

pop :: State Stack Int
pop = State $ (x:xs) -> (x,xs)

push :: Int -> State Stack ()
push a = State $ \xs -> ((),a:xs)

The push and pop operations are state transformers that takes an input state (the stack implemented as a regular list), transforms the state and possibly output a value.

The difference of using these transformers shows when using them in a composed stateful computation. The stackManip is translated to the composed state transformer below. Note that each state manipulation doesn't need to explicitely define sub-states because this is (generally) taken care of by the bind (>>=) operation for State monads.

stackManip :: State Stack Int
stackManip = do
    push 3
    a <- pop
    pop

The actual state transform functions is hidden behind the runState parameter of the State type.

newtype State s a = State { runState :: s -> (a,s) }

To perform the computation you just need to call the stateful computation with the input state as input.

ghci> runState stackManip [5,8,2,1]  
(5,[8,2,1])  

So, using State monad removes the need to explicitely state each sub-state in a composed stateful computation.

Comparison with other monads

Reader and Writer monads have similarities with the State monad.

The Reader monad is a function where the input value is implicit. You can also see it as being able to create functions where a common variable (or environment) is always available in each of the monad transformations building up a composite function.

instance Monad ((->) r) where
    return x = \_ -> x
    h >>= f = \w -> f (h w) w

In the example from LYaH: Reader? Ugh, not this joke again a set of functions are applied on an implicit input value.

addStuff :: Int -> Int
addStuff = do
    a <- (*2)
    b <- (+10)
    return (a+b)

The same composite function with an explicit input parameter looks like the following.

addStuff :: Int -> Int
addStuff x = let
    a = (*2) x
    b = (+10) x
    in a+b

This is similar to State monad in that the input state is implicit in each step of a composite state transformation.

The State monad have a way to implicitely change the state in each composite transformation. The Writer monad also have an implicit value (e.g. a log value) which can be modified in each transformation.

instance (Monoid w) => Monad (Writer w) where
    return x = Writer (x, mempty)
    (Writer (x,v)) >>= f = let (Writer (y, v')) = f x in Writer (y, v `mappend` v')

However while the State monad can apply arbitrary transformations to the implicit state, the Writer monad only allow appending to the value.

So you could use the State monad to achieve both the purpose of Reader monad and the Writer monad. The state of the State monad could be used as an environment, used in the Reader monad, and the state transformations of the state could be used to keep a log for the computations, used in the Writer monad. Reader and Writer are however more restrictive than State and you can select only one of the two aspects when you don't need both.

The IO monad could also be compared with the State monad. IO operations could be seen as state transformations with the state being the environment outside of the program (aka "world"). A read operation read from the world state and a write operation write to the world state.

The main function of a Haskell program can in theory be seens as running the state transformation included in the program (main) with the world as input state.

runState main world
world'

The output state (world') has all the changes (e.g. write operations) that this program made to the world.

It is especially userful to have an implicit state when working with the world as state. It would be impractical to explicitely state the world as a valie when the format and shape isn't defined in practice. It is a mere abstraction that explains how an haskell program relates to the world during execution.

Understanding bind for functions

First step is to understand how bind (>>=) function works for functions.

instance Monad ((->) r) where  
  return x = \_ -> x  
  h >>= f = \w -> f (h w) w 

And some examples using the bind function compared with Maybe monad.

Just 1 >>= (\a -> Just (a+2)) >>= (\b -> Just (b+3))    -- not using previous results
Just 6
Just 1 >>= (\a -> (Just (a+2) >>= (\b -> Just (a+b))))  -- using previous results 
Just 4

let f = (*2) >>= (\a -> (+10)) >>= (return)             -- (*2) is not used
f 3
10
let f = (*2) >>= (\a -> (+10) >>= (\b -> return (a+b)))
f 3
19

References