OK, now this exception-handling apparatus does exemplify the second execution pattern we want to focus on. But it may bring it into clearer focus if we **simplify the pattern** even more. Imagine we could write code like this instead:
- # let foo x =
- try begin
- (if x = 1 then 10
- else abort 20
- ) + 100
- end
- ;;
+ let foo x =
+ try begin
+ (if x = 1 then 10
+ else abort 20
+ ) + 100
+ end
then if we called `foo 1`, we'd get the result `110`. If we called `foo 2`, on the other hand, we'd get `20` (note, not `120`). This exemplifies the same interesting "jump out of this part of the code" behavior that the `try ... raise ... with ...` code does, but without the details of matching which exception was raised, and handling the exception to produce a new result.
-Many programming languages have this simplified exceution pattern, either instead of or alongside a `try ... with ...`-like pattern. In Lua and many other languages, `abort` is instead called `return`. In Lua, the preceding example would be written:
+> If we had to write that using `try...with...`, it'd look something like this:
+
+> exception Abort of int;; (* declare a new type of exception that can carry an int parameter *)
+> let foo x =
+> try
+> (if x = 1 then 10
+> else raise (Abort 20)
+> ) + 100
+> with Abort n -> n
+
+Many programming languages have this simplified execution pattern, either instead of or alongside a `try ... with ...`-like pattern. In Lua and many other languages, `abort` is instead called `return`. In Lua, the preceding example would be written:
> function foo(x)
local value
else abort 20
) + 100
end
- in (foo 2) + 1;; (* this line is new *)
+ in (foo 2) + 1000;; (* this line is new *)
we can imagine a box:
(shift k
(if (eqv? x 1) (k 10) 20))
100)))])
- (+ (foo 1) 1000))
-
+ (+ (foo 2) 1000))
-And in OCaml:
-<pre>
+<!--
# #require "delimcc";;
# open Delimcc;;
# let reset body = let p = new_prompt () in push_prompt p (body p);;
- : int = 1020
# test_shift 2;;
- : int = 1020
-</pre>
+-->
+
Various of the tools we've been introducing over the past weeks are inter-related. We saw coroutines implemented first with zippers; here we've talked in the abstract about their being implemented with continuations. Oleg says that "Zipper can be viewed as a delimited continuation reified as a data structure." Ken expresses the same idea in terms of a zipper being a "defunctionalized" continuation---that is, take something implemented as a function (a continuation) and implement the same thing as an inert data structure (a zipper).