tweak advanced

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

diff --git a/miscellaneous_lambda_challenges_and_advanced_topics.mdwn b/miscellaneous_lambda_challenges_and_advanced_topics.mdwn
index 0342fc6..37f2a10 100644 (file)
--- a/miscellaneous_lambda_challenges_and_advanced_topics.mdwn
+++ b/miscellaneous_lambda_challenges_and_advanced_topics.mdwn
@@ -378,19 +378,19 @@ can use.
 
                ; and so on             
                
-       Remarks: the `larger_computation_handler` should be supplied as both the
+       Remarks: the `larger_computation` handler should be supplied as both the
        `continue_leftwards_handler` and the `abort_handler` for the leftmost
-       application, where the head `5` is supplied to `f`. Because the result of this
+       application, where the head `5` is supplied to `f`; because the result of this
        application should be passed to the larger computation, whether it's a "fall
        off the left end of the list" result or it's a "I'm finished, possibly early"
-       result. The `larger_computation_handler` also then gets passed to the next
+       result. The `larger_computation` handler also then gets passed to the next
        rightmost stage, where the head `4` is supplied to `f`, as the `abort_handler` to
        use if that stage decides it has an early answer.
 
        Finally, notice that we don't have the result of applying `f` to `4` etc given as
        an argument to the application of `f` to `5` etc. Instead, we pass
 
-               (\result_of_fold_over_4321. f 5 result_of_fold_over_4321 one_handler another_handler)
+               (\result_of_fold_over_4321. f 5 result_of_fold_over_4321 <one_handler> <another_handler>)
 
        *to* the application of `f` to `4` as its "continue" handler. The application of `f`
        to `4` can decide whether this handler, or the other, "abort" handler, should be
@@ -402,8 +402,8 @@ can use.
        of the complex expression semantically depending only on this, not on that. A
        demon evaluator who custom-picked the evaluation order to make things maximally
        bad for you could ensure that all the semantically unnecessary computations got
-       evaluated anyway. At this stage, we don't have any way to prevent that. Later,
-       we'll see ways to semantically guarantee one evaluation order rather than
+       evaluated anyway. We don't have any way to prevent that. Later,
+       we'll see ways to *semantically guarantee* one evaluation order rather than
        another. Though even then the demonic evaluation-order-chooser could make it
        take unnecessarily long to compute the semantically guaranteed result. Of
        course, in any real computing environment you'll know you're dealing with a