在州monad中使用put with >>

Question

From Thinking Functionally with Haskell (pg 248):

You can think of type State sa as being

 type State sa = s -> (a,s) 

...

 put :: s -> State s () get :: State ss state :: (s -> (a,s)) -> State sa 

... state can be defined using put and get :

 state f = do {s <- get; let (a,s') = fs; put s'; return a} 

Which I believe can be rewritten this way:

get >>= \s ->
    let (a,s') = fs in
        put s' >> return a

So what is the purpose of put s' , if >> throws away its return value?

Answer 1

>> doesn't throw away everything from the first argument. The definition for the state monad (ignoring the newtype )

a >> b = \s -> let (x, s') = a s in b s'

So the state form the first argument is used by >> , but the 'return value' (the x component of the result) is ignored. That's the point of the state monad --- to track changes to the state without the programmer having to explicitly take them into account.

Apparently, this isn't explained properly by what the OP has been reading, so here's how you can derive the definition above. The definition of >> across all monads is

a >> b = a >>= \ _ -> b

The definition of >>= for the state monad (ignoring newtype s) is

a >>= f = \ s -> let (x, s') = a s in f x s'

Now, substituting the definition of >>= into the definition of >> above and simplifying, we get:

a >> b = let f = \ _ -> b in \ s -> let (x, s') = a s in f x s'
    = \ s -> let (x, s') = a s in (\ _ -> b) x s'
    = \ s -> let (x, s') = a s in b s'

Answer 2

So what is the purpose of put s' , if >> throws away its return value?

(>>) does throw away the return value, but we don't use put for the return value. The type of put is:

put :: s -> State s ()

The return value is of put is a () , and () is for the most part just an uninteresting placeholder. The meaningful part of what put does -- replacing the state -- is not reflected in the return value. A similar case is the type of putStrLn :: String -> IO () .

Answer 3

State is an example where the monad abstraction is used to encapsulate an effect . In such cases, it's perfectly normal to have operations in which the effect of the operation is important, but it might not have a meaningful return value.

I'll illustrate with an example. Consider everyone's favorite recursive algorithm, the Fibonacci sequence:

fib :: Int -> Int
fib 1 = 0
fib 2 = 1
fib n = fib (n-1) + fib (n-2)

We all know this is a pretty inefficient way to calculate these numbers, but how inefficient is it? If we were using a lesser language, we would probably be tempted to hack in a mutable variable and increment it every time fib is called. We can do something similar in Haskell in a purely functional way using State .

Let's define a new version of fib:

fib' :: Int -> State Int Int
fib' 1 = modify (+1) >> return 0
fib' 2 = modify (+1) >> return 1
fib' n = modify (+1) >> (+) <$> fib' (n-1) <*> fib' (n-2)

Now we can simultaneously compute the nth number and also count how many calls were made:

> runState (fib' 7) 0
(8,25)
> runState (fib' 10) 0
(34,109)
> runState (fib' 30) 0  -- this takes about 5 seconds on my machine
(514229,1664079)

Ok, that's great but how does it answer the question? The point to note in the above implementation is modify (+1) . This has the effect of adding 1 to the counter, but doesn't have any useful result on its own. We use >> to sequence it with the next operation, which does have a useful result, namely the computation.