From 1c1ffe645eb7ae7dd3f76e9cb0d60c7eba8657e6 Mon Sep 17 00:00:00 2001
From: Jim Pryor
Date: Wed, 1 Dec 2010 01:42:54 -0500
Subject: [PATCH] lists-monad tweaks
Signed-off-by: Jim Pryor
---
list_monad_as_continuation_monad.mdwn | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
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
--
2.11.0