XGitUrl: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=zipperlistscontinuations.mdwn;h=de13fe944dce0d801ac9db3d7e63723e09642c7c;hp=745cf29d9fabefbbd6226c6a40cbd9b67ca9f4f3;hb=df9890f3336c7796dc079f6cf41ba9b4ab0ae0af;hpb=f1012badf41d0d6d52dc849603eaca8aeb752b0b
diff git a/zipperlistscontinuations.mdwn b/zipperlistscontinuations.mdwn
index 745cf29d..de13fe94 100644
 a/zipperlistscontinuations.mdwn
+++ b/zipperlistscontinuations.mdwn
@@ 373,9 +373,6 @@ and that this monad can reproduce the behavior of the standard list
monad. But what about other list implementations? Do they give rise
to monads that can be understood in terms of continuations?
Refunctionalizing zippers


Manipulating trees with monads

@@ 770,8 +767,8 @@ that is intended to
represent nondeterministic computations as a tree.
Lists, zippers, continuations

+Refunctionalizing zippers: from lists to continuations
+
Let's work with lists of chars for a change. To maximize readability, we'll
indulge in an abbreviatory convention that "abc" abbreviates the
@@ 833,7 +830,7 @@ Aparently, this task, as simple as it is, is a form of computation,
and the order in which the `'S'`s get evaluated can lead to divergent
behavior.
For now, as usual, we'll agree to always ``evaluate'' the leftmost `'S'`.
+For now, as usual, we'll agree to always evaluate the leftmost `'S'`.
This is a task wellsuited to using a zipper.
@@ 841,9 +838,9 @@ This is a task wellsuited to using a zipper.
type 'a list_zipper = ('a list) * ('a list);;
let rec t1 (z:char list_zipper) =
 match z with (sofar, []) > List.rev(sofar)
  (sofar, 'S'::rest) > t1 ((List.append sofar sofar), rest)
  (sofar, fst::rest) > t1 (fst::sofar, rest);;
+ match z with (sofar, []) > List.rev(sofar) (* Done! *)
+  (sofar, 'S'::rest) > t1 ((List.append sofar sofar), rest)
+  (sofar, fst::rest) > t1 (fst::sofar, rest);; (* Move zipper *)
# t1 ([], ['a'; 'b'; 'S'; 'e']);;
 : char list = ['a'; 'b'; 'a'; 'b'; 'e']
@@ 855,9 +852,42 @@ let rec t1 (z:char list_zipper) =
Note that this implementation enforces the evaluateleftmost rule.
Task 1 completed.
+The nice thing about computations involving lists is that it's so easy
+to visualize them as a data structure. Eventually, we want to get to
+a place where we can talk about more abstract computations. In order
+to get there, we'll first do the exact same thing we just did with
+concrete zipper using procedures.
+
+Think of a list as a procedural recipe: `['a'; 'b'; 'c']` means (1)
+start with the empty list `[]`; (2) make a new list whose first
+element is 'c' and whose tail is the list construted in the previous
+step; (3) make a new list whose first element is 'b' and whose tail is
+the list constructed in the previous step; and (4) make a new list
+whose first element is 'a' and whose tail is the list constructed in
+the previous step.
+
+What is the type of each of these steps? Well, it will be a function
+from the result of the previous step (a list) to a new list: it will
+be a function of type `char list > char list`. We'll call each step
+a **continuation** of the recipe. So in this context, a continuation
+is a function of type `char list > char list`.
+
+This means that we can now represent the sofar part of our zipperthe
+part we've already unzippedas a continuation, a function describing
+how to finish building the list:
++let rec t1c (l: char list) (c: (char list) > (char list)) =
+ match l with [] > c []
+  'S'::rest > t1c rest (fun x > c (c x))
+  a::rest > t1c rest (fun x > List.append (c x) [a]);;
+# t1c ['a'; 'b'; 'S'] (fun x > x);;
+ : char list = ['a'; 'b'; 'a'; 'b']
+# t1c ['a'; 'S'; 'b'; 'S'] (fun x > x);;
+ : char list = ['a'; 'a'; 'b'; 'a'; 'a'; 'b']
+
+Note that we don't need to do any reversing.
