coroutines tweak

Signed-off-by: Jim Pryor <profjim@jimpryor.net>

diff --git a/coroutines_and_aborts.mdwn b/coroutines_and_aborts.mdwn
index b906639..0afd239 100644 (file)
--- a/coroutines_and_aborts.mdwn
+++ b/coroutines_and_aborts.mdwn
@@ -359,7 +359,7 @@ The matching `try ... with ...` block need not *lexically surround* the site whe
        in foo bar 0;;
        - : int = 20
 
        in foo bar 0;;
        - : int = 20
 

-Here we call `foo bar 0`, and `foo` in turn calls `bar 0`, and `bar` raises the exception. Since there's no matching `try ... with ...` block in `bar`, we percolate back up the history of *who called this function?* and find a matching `try ... with ...` block in `foo`. This catches the error and so then the `try ... with ...` block in `foo` that called `bar` in the first place will evaluate to `20`.
+Here we call `foo bar 0`, and `foo` in turn calls `bar 0`, and `bar` raises the exception. Since there's no matching `try ... with ...` block in `bar`, we percolate back up the history of who called that function, and we find a matching `try ... with ...` block in `foo`. This catches the error and so then the `try ... with ...` block in `foo` (the code that called `bar` in the first place) will evaluate to `20`.

 
 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:
 
 
 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: