1 This walks through most of [A State Monad Tutorial](http://strabismicgobbledygook.wordpress.com/2010/03/06/a-state-monad-tutorial/), which is addressed to a Haskell-using audience. But we convert it to OCaml. See our page on

10 It's common practice to encapsulate this in some way, so that the interpreter knows the difference between arbitrary functions from a `blah` to a pair of something and a `blah` and the values that you've specially designated as being State monadic values.

12 The most lightweight way encapsulate it would be just to add a data constructor to the type. In the same way that the `'a option` type has the `None` and `Some` data constructors, we give our `'a state` type a `State` data constructor:

31 There are two heavierweight ways to encapsulate the type of the State monad. One is used by our [[monad library]]---the type is hidden from the outside user, and only gets exposed by the `run` function. But the result of `run u` is not itself recognized as a monadic value any longer. You can't replace `u` in:

45 The other heavyweight way to encapsulate the type of a monad is to use records. See [here](/translating_between_OCaml_Scheme_and_Haskell) and [here](/coroutines_and_aborts/) for some introduction to these. We don't use this design in our OCaml monad library, but the Haskell monad libraries do, and it would be good for you to get acquainted with it so that you can see how to ignore it when you come across it in Haskell-based literature. (Or you might want to learn Haskell, who knows?)

71 The main benefit of these techniques is that it gives you better type-checking: it makes sure that you're only using your monadic values in the hygenic ways you're supposed to. Perhaps you don't care about that. Well, then, if you want to write all your own monadic code, you can proceed as you like. If you ever want to use other people's code, though, or read papers or web posts about monads, you will encounter one or more of these techniques, and so you need to get comfortable enough with them not to let them confuse you.

73 OK, back to our walk-through of "A State Monad Tutorial". What shall we use for a store? Instead of a plain `int`, let's suppose our store is a structure of two values: a running total, and a count of how many times the store has been modified. We'll implement this with a record. Hence:

77 State monads employing this store will then have *three* salient values at any point in the computation: the `total` and `modifications` field in the store, and also the `'a` value that is then wrapped in the monadic box.

121 What about a value that increments each of `total` and `modifications` twice? Well, you could custom-write that, as with the previous question. But we already have the tools to express it easily, using our existing `increment_store` value:

125 That ensures that the value we get at the end is the value returned by the first application of `increment_store`, that is, the contents of the `total` field in the store before we started modifying the store at all.

127 You should start to see here how chaining monadic values together gives us a kind of programming language. Of course, it's a cumbersome programming language. It'd be much easier to write, directly in OCaml:

137 But **the point of learning how to do this monadically** is that (1) monads show us how to embed more sophisticated programming techniques, such as imperative state and continuations, into frameworks that don't natively possess them (such as the set-theoretic metalanguage of Groenendijk, Stokhof and Veltman's paper); (2) becoming familiar with monads will enable you to see patterns you'd otherwise miss, and implement some seemingly complex computations using the same simple patterns (same-fringe is an example); and finally, of course (3) monads are delicious.

163 * `gets selector` is like `get`, but it additionally applies the `selector` function to the store before depositing it in the box. If your store is structured, you can use this to only extract a piece of the structure:

179 Haskell calls this operation `modify`. We've called it `puts` because it seems to fit naturally with the convention of `get` vs `gets`. (See also `ask` vs `asks` in `Reader_monad`, which are also the names used in Haskell.)

195 The last topic covered in "A State Monad Tutorial" is the use of do-notation to work with monads in Haskell. We discuss that on our [translation page](/translating_between_OCaml_Scheme_and_Haskell).