-11. Here's a comparison of `let/cc` to `shift`. Recall example 2 above was:
- <pre><b>100 + </b>let/cc k (10 + k 1)</pre>
- which evaluated to `101`. The parallel code where we instead capture the continuation using `shift k ( ... )` would look like this:
- <pre>reset <b>(100 + </b>shift k (10 + k 1)<b>)</b></pre>
- But this evaluates differently. In the `let/cc` example, `k` is bound to the rest of the computation *including its termination*, so after executing `k 1` we never come back and finish with `10 + < >`. A `let/cc`-bound `k` never returns to the context where it was invoked. Whereas the `shift`-bound `k` only includes up to the edge of the `reset` box --- here, the rest of the computation, but *not including* its termination. So after `k 1`, if there is still code inside the body of `shift`, as there is here, we continue executing it. Thus the `shift` code evaluates to `111` not to `101`.
+11. Here's another comparison of `let/cc` to `shift`. Recall example 2 above was:
+ <pre><b>100 + </b>let/cc k. (10 + k 1)</pre>
+ which evaluated to `101`. The parallel code where we instead capture the continuation using `shift k. ( ... )` would look like this:
+ <pre>reset <b>(100 + </b>shift k. (10 + k 1)<b>)</b></pre>
+ But this evaluates differently, as we saw in example 8. In the `let/cc` example, `k` is bound to the rest of the computation *including its termination*, so after executing `k 1` we never come back and finish with `10 + < >`. A `let/cc`-bound `k` never returns to the context where it was invoked. Whereas the `shift`-bound `k` only includes up to the edge of the `reset` box --- here, the rest of the computation, but *not including* its termination. So after `k 1`, if there is still code inside the body of `shift`, as there is here, we continue executing it. Thus the `shift` code evaluates to `111` not to `101`.