moved index to .pdc
[lambda.git] / from_list_zippers_to_continuations.mdwn
index 1ef5f9c..dcd11ce 100644 (file)
@@ -6,9 +6,9 @@ to continuations is to re-functionalize a zipper.  Then the
 concreteness and understandability of the zipper provides a way of
 understanding an equivalent treatment using continuations.
 
-Let's work with lists of `char`s for a change.  To maximize readability, we'll
-indulge in an abbreviatory convention that "abSd" abbreviates the
-list `['a'; 'b'; 'S'; 'd']`.
+Let's work with lists of `char`s for a change.  We'll sometimes write
+"abSd" as an abbreviation for  
+`['a'; 'b'; 'S'; 'd']`.
 
 We will set out to compute a deceptively simple-seeming **task: given a
 string, replace each occurrence of 'S' in that string with a copy of
@@ -70,7 +70,8 @@ This is a task well-suited to using a zipper.  We'll define a function
 `char list zipper` to a `char list`.  We'll call the two parts of the
 zipper `unzipped` and `zipped`; we start with a fully zipped list, and
 move elements to the unzipped part by pulling the zipper down until the
-entire list has been unzipped (and so the zipped half of the zipper is empty).
+entire list has been unzipped, at which point the zipped half of the
+zipper will be empty.
 
        type 'a list_zipper = ('a list) * ('a list);;
        
@@ -86,14 +87,15 @@ entire list has been unzipped (and so the zipped half of the zipper is empty).
        # tz ([], ['a'; 'S'; 'b'; 'S']);;
        - : char list = ['a'; 'a'; 'b'; 'a'; 'a'; 'b']
 
-Note that this implementation enforces the evaluate-leftmost rule.
-Task completed.
+Note that the direction in which the zipper unzips enforces the
+evaluate-leftmost rule.  Task completed.
 
 One way to see exactly what is going on is to watch the zipper in
 action by tracing the execution of `tz`.  By using the `#trace`
 directive in the OCaml interpreter, the system will print out the
-arguments to `tz` each time it is (recursively) called.  Note that the
-lines with left-facing arrows (`<--`) show (recursive) calls to `tz`,
+arguments to `tz` each time it is called, including when it is called
+recursively within one of the `match` clauses.  Note that the
+lines with left-facing arrows (`<--`) show (both initial and recursive) calls to `tz`,
 giving the value of its argument (a zipper), and the lines with
 right-facing arrows (`-->`) show the output of each recursive call, a
 simple list.
@@ -101,10 +103,10 @@ simple list.
        # #trace tz;;
        t1 is now traced.
        # tz ([], ['a'; 'b'; 'S'; 'd']);;
-       tz <-- ([], ['a'; 'b'; 'S'; 'd'])
+       tz <-- ([], ['a'; 'b'; 'S'; 'd'])       (* Initial call *)
        tz <-- (['a'], ['b'; 'S'; 'd'])         (* Pull zipper *)
        tz <-- (['b'; 'a'], ['S'; 'd'])         (* Pull zipper *)
-       tz <-- (['b'; 'a'; 'b'; 'a'], ['d'])    (* Special step *)
+       tz <-- (['b'; 'a'; 'b'; 'a'], ['d'])    (* Special 'S' step *)
        tz <-- (['d'; 'b'; 'a'; 'b'; 'a'], [])  (* Pull zipper *)
        tz --> ['a'; 'b'; 'a'; 'b'; 'd']        (* Output reversed *)
        tz --> ['a'; 'b'; 'a'; 'b'; 'd']
@@ -119,14 +121,14 @@ 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 instead.
 
-Think of a list as a procedural recipe: `['a'; 'b'; 'S'; 'd']` is the result of
-the computation `'a'::('b'::('S'::('d'::[])))` (or, in our old style,
-`make_list 'a' (make_list 'b' (make_list 'S' (make_list 'd' empty)))`). The
+Think of a list as a procedural recipe: `['a'; 'b'; 'c'; 'd']` is the result of
+the computation `'a'::('b'::('c'::('d'::[])))` (or, in our old style,
+`make_list 'a' (make_list 'b' (make_list 'c' (make_list 'd' empty)))`). The
 recipe for constructing the list goes like this:
 
 >      (0)  Start with the empty list []  
 >      (1)  make a new list whose first element is 'd' and whose tail is the list constructed in step (0)  
->      (2)  make a new list whose first element is 'S' and whose tail is the list constructed in step (1)  
+>      (2)  make a new list whose first element is 'c' and whose tail is the list constructed in step (1)  
 >      -----------------------------------------  
 >      (3)  make a new list whose first element is 'b' and whose tail is the list constructed in step (2)  
 >      (4)  make a new list whose first element is 'a' and whose tail is the list constructed in step (3)
@@ -138,16 +140,11 @@ be a function of type `char list -> char list`.  We'll call each step
 context, a continuation is a function of type `char list -> char
 list`.  For instance, the continuation corresponding to the portion of
 the recipe below the horizontal line is the function `fun (tail : char
-list) -> 'a'::('b'::tail)`.
+list) -> 'a'::('b'::tail)`. What is the continuation of the 4th step? That is, after we've built up `'a'::('b'::('c'::('d'::[])))`, what more has to happen to that for it to become the list `['a'; 'b'; 'c'; 'd']`? Nothing! Its continuation is the function that does nothing: `fun tail -> tail`.
 
-This means that we can now represent the unzipped part of our
-zipper as a continuation: a function
-describing how to finish building a list.  We'll write a new
-function, `tc` (for task with continuations), that will take an input
-list (not a zipper!) and a continuation `k` (it's conventional to use `k` for continuation variables) and return a processed list.
-The structure and the behavior will follow that of `tz` above, with
-some small but interesting differences.  We've included the orginal
-`tz` to facilitate detailed comparison:
+In what follows, we'll be thinking about the result list that we're building up in this procedural way. We'll treat our input list just as a plain old static list data structure, that we recurse through in the normal way we're accustomed to. We won't need a zipper data structure, because the continuation-based representation of our result list will take over the same role.
+
+So our new function `tc` (for task with continuations) takes an input list (not a zipper) and a also takes a continuation `k` (it's conventional to use `k` for continuation variables). `k` is a function that represents how the result list is going to continue being built up after this invocation of `tc` delivers up a value. When we invoke `tc` for the first time, we expect it to deliver as a value the very de-S'd list we're seeking, so the way for the list to continue being built up is for nothing to happen to it. That is, our initial invocation of `tc` will supply `fun tail -> tail` as the value for `k`. Here is the whole `tc` function. Its structure and behavior follows `tz` from above, which we've repeated here to facilitate detailed comparison:
 
        let rec tz (z : char list_zipper) =
            match z with
@@ -170,15 +167,16 @@ some small but interesting differences.  We've included the orginal
 To emphasize the parallel, we've re-used the names `zipped` and
 `target`.  The trace of the procedure will show that these variables
 take on the same values in the same series of steps as they did during
-the execution of `tz` above.  There will once again be one initial and
+the execution of `tz` above: there will once again be one initial and
 four recursive calls to `tc`, and `zipped` will take on the values
 `"bSd"`, `"Sd"`, `"d"`, and `""` (and, once again, on the final call,
 the first `match` clause will fire, so the the variable `zipped` will
 not be instantiated).
 
-We have not called the functional argument `unzipped`, although that is
-what the parallel would suggest.  The reason is that `unzipped` is a
-list, but `k` is a function.  That's the most crucial difference, the
+We have not named the continuation argument `unzipped`, although that is
+what the parallel would suggest.  The reason is that `unzipped` (in
+`tz`) is a list, but `k` (in `tc`) is a function.  That's the most crucial 
+difference between the solutions---it's the
 point of the excercise, and it should be emphasized.  For instance,
 you can see this difference in the fact that in `tz`, we have to glue
 together the two instances of `unzipped` with an explicit (and,
@@ -186,21 +184,26 @@ computationally speaking, relatively inefficient) `List.append`.
 In the `tc` version of the task, we simply compose `k` with itself:
 `k o k = fun tail -> k (k tail)`.
 
-A call `tc ['a'; 'b'; 'S'; 'd']` yields a partially-applied function; it still waits for another argument, a continuation of type `char list -> char list`. We have to give it an "initial continuation" to get started. Here we supply *the identity function* as the initial continuation. Why did we choose that? Well, if
-you have already constructed the initial list `"abSd"`, what's the desired continuation? What's the next step in the recipe to produce the desired result, i.e, the very same list, `"abSd"`?  Clearly, the identity function.
+A call `tc ['a'; 'b'; 'S'; 'd']` would yield a partially-applied function; it would still wait for another argument, a continuation of type `char list -> char list`. So we have to give it an "initial continuation" to get started. As mentioned above, we supply *the identity function* as the initial continuation. Why did we choose that? Again, if
+you have already constructed the result list `"ababd"`, what's the desired continuation? What's the next step in the recipe to produce the desired result, i.e, the very same list, `"ababd"`?  Clearly, the identity function.
 
 A good way to test your understanding is to figure out what the
 continuation function `k` must be at the point in the computation when
-`tc` is called with the first argument `"Sd"`.  Two choices: is it
-`fun tail -> 'a'::'b'::tail`, or it is `fun tail -> 'b'::'a'::tail`?  The way to see if
-you're right is to execute the following command and see what happens:
+`tc` is applied to the argument `"Sd"`.  Two choices: is it
+`fun tail -> 'a'::'b'::tail`, or it is `fun tail -> 'b'::'a'::tail`?  The way to see if you're right is to execute the following command and see what happens:
 
     tc ['S'; 'd'] (fun tail -> 'a'::'b'::tail);;
 
 There are a number of interesting directions we can go with this task.
-The reason this task was chosen is because it can be viewed as a
+The reason this task was chosen is because the task itself (as opposed
+to the functions used to implement the task) can be viewed as a
 simplified picture of a computation using continuations, where `'S'`
-plays the role of a continuation operator. (It works like the Scheme operators `shift` or `control`; the differences between them don't manifest themselves in this example.) In the analogy, the input list portrays a
+plays the role of a continuation operator. (It works like the Scheme
+operators `shift` or `control`; the differences between them don't
+manifest themselves in this example.
+See Ken Shan's paper [Shift to control](http://www.cs.rutgers.edu/~ccshan/recur/recur.pdf),
+which inspired some of the discussion in this topic.)
+In the analogy, the input list portrays a
 sequence of functional applications, where `[f1; f2; f3; x]` represents
 `f1(f2(f3 x))`.  The limitation of the analogy is that it is only
 possible to represent computations in which the applications are
@@ -213,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.