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