Then our unit is naturally:
- let s_unit (a : 'a) : ('a state) = fun (s : store) -> (a, s)
+ let s_unit (a : 'a) : 'a state = fun (s : store) -> (a, s)
And we can reason our way to the bind function in a way similar to the reasoning given above. First, we need to apply `f` to the contents of the `u` box:
List.map (fun i -> [i;i+1]) [1;2] ~~> [[1; 2]; [2; 3]]
-and List.concat takes a list of lists and erases the embedded list
+and `List.concat` takes a list of lists and erases the embedded list
boundaries:
List.concat [[1; 2]; [2; 3]] ~~> [1; 2; 2; 3]
Now, why this unit, and why this bind? Well, ideally a unit should
not throw away information, so we can rule out `fun x -> []` as an
ideal unit. And units should not add more information than required,
-so there's no obvious reason to prefer `fun x -> [x,x]`. In other
+so there's no obvious reason to prefer `fun x -> [x;x]`. In other
words, `fun x -> [x]` is a reasonable choice for a unit.
As for bind, an `'a list` monadic object contains a lot of objects of
the object returned by the second argument of `bind` to always be of
type `'b list list`. We can eliminate that restriction by flattening
the list of lists into a single list: this is
-just List.concat applied to the output of List.map. So there is some logic to the
+just `List.concat` applied to the output of `List.map`. So there is some logic to the
choice of unit and bind for the list monad.
Yet we can still desire to go deeper, and see if the appropriate bind