lists-monad tweaks
authorJim Pryor <profjim@jimpryor.net>
Wed, 1 Dec 2010 06:42:54 +0000 (01:42 -0500)
committerJim Pryor <profjim@jimpryor.net>
Wed, 1 Dec 2010 06:42:54 +0000 (01:42 -0500)
Signed-off-by: Jim Pryor <profjim@jimpryor.net>
list_monad_as_continuation_monad.mdwn

index 6354c40..a97e7e3 100644 (file)
@@ -114,7 +114,7 @@ result to applying the function to the elements of the list:
 
        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]
@@ -126,7 +126,7 @@ And sure enough,
 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
@@ -140,7 +140,7 @@ possibility is that we could gather them all up in a list, so that
 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