From b7aef174959119fd62706cd966ca74859bbdf292 Mon Sep 17 00:00:00 2001 From: Jim Pryor Date: Thu, 2 Dec 2010 09:22:20 -0500 Subject: [PATCH] tweak week12: caps Signed-off-by: Jim Pryor --- from_list_zippers_to_continuations.mdwn | 2 +- manipulating_trees_with_monads.mdwn | 22 +++++++++++----------- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/from_list_zippers_to_continuations.mdwn b/from_list_zippers_to_continuations.mdwn index 59185df5..713fe352 100644 --- a/from_list_zippers_to_continuations.mdwn +++ b/from_list_zippers_to_continuations.mdwn @@ -216,7 +216,7 @@ the closest `'#'`. This would allow our task to simulate delimited continuations with embedded `prompt`s (also called `reset`s). The reason the task is well-suited to the list zipper is in part -because the list monad has an intimate connection with continuations. +because the List monad has an intimate connection with continuations. We'll explore this next. diff --git a/manipulating_trees_with_monads.mdwn b/manipulating_trees_with_monads.mdwn index e7cccecd..e3ed6f3a 100644 --- a/manipulating_trees_with_monads.mdwn +++ b/manipulating_trees_with_monads.mdwn @@ -13,7 +13,7 @@ From an engineering standpoint, we'll build a tree transformer that deals in monads. We can modify the behavior of the system by swapping one monad for another. We've already seen how adding a monad can add a layer of funtionality without disturbing the underlying system, for -instance, in the way that the reader monad allowed us to add a layer +instance, in the way that the Reader monad allowed us to add a layer of intensionality to an extensional grammar, but we have not yet seen the utility of replacing one monad with other. @@ -84,11 +84,11 @@ supplying the appropriate `int -> int` operation in place of `double`: Note that what `tree_map` does is take some unchanging contextual information---what to do to each leaf---and supplies that information to each subpart of the computation. In other words, `tree_map` has the -behavior of a reader monad. Let's make that explicit. +behavior of a Reader monad. Let's make that explicit. In general, we're on a journey of making our `tree_map` function more and more flexible. So the next step---combining the tree transformer with -a reader monad---is to have the `tree_map` function return a (monadized) +a Reader monad---is to have the `tree_map` function return a (monadized) tree that is ready to accept any `int -> int` function and produce the updated tree. @@ -190,7 +190,7 @@ result: Now that we have a tree transformer that accepts a *reader* monad as a parameter, we can see what it would take to swap in a different monad. -For instance, we can use a state monad to count the number of leaves in +For instance, we can use a State monad to count the number of leaves in the tree. type 'a state = int -> 'a * int;; @@ -238,7 +238,7 @@ One more revealing example before getting down to business: replacing Unlike the previous cases, instead of turning a tree into a function from some input to a result, this transformer replaces each `int` with -a list of `int`'s. We might also have done this with a Reader Monad, though then our environments would need to be of type `int -> int list`. Experiment with what happens if you supply the `tree_monadize` based on the List Monad an operation like `fun -> [ i; [2*i; 3*i] ]`. Use small trees for your experiment. +a list of `int`'s. We might also have done this with a Reader monad, though then our environments would need to be of type `int -> int list`. Experiment with what happens if you supply the `tree_monadize` based on the List monad an operation like `fun -> [ i; [2*i; 3*i] ]`. Use small trees for your experiment.