From 08fe47cd79e1dff91bf5c764c103fcb05c1abac2 Mon Sep 17 00:00:00 2001 From: Jim Pryor Date: Sun, 3 Oct 2010 02:37:32 -0400 Subject: [PATCH] tweak advanced Signed-off-by: Jim Pryor --- miscellaneous_lambda_challenges_and_advanced_topics.mdwn | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/miscellaneous_lambda_challenges_and_advanced_topics.mdwn b/miscellaneous_lambda_challenges_and_advanced_topics.mdwn index 0342fc64..37f2a102 100644 --- 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 ) *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 -- 2.11.0