Signed-off-by: Jim Pryor <profjim@jimpryor.net>
- 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
`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"
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
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
*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
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
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
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