From: Jim Pryor
Date: Wed, 1 Dec 2010 06:42:54 +0000 (-0500)
Subject: lists-monad tweaks
X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=commitdiff_plain;h=1c1ffe645eb7ae7dd3f76e9cb0d60c7eba8657e6
lists-monad tweaks
Signed-off-by: Jim Pryor
---
diff --git a/list_monad_as_continuation_monad.mdwn b/list_monad_as_continuation_monad.mdwn
index 6354c407..a97e7e36 100644
--- a/list_monad_as_continuation_monad.mdwn
+++ b/list_monad_as_continuation_monad.mdwn
@@ -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