rather than the handler taking the pair as an argument. (The handler gets *the
pair's elements*, not the pair itself, as arguments.)
- *Terminology*: we'll try to use names of the form `get_foo` for handlers, and
+ > *Terminology*: we'll try to use names of the form `get_foo` for handlers, and
names of the form `extract_foo` for lifted versions of them, that accept the
lists (or whatever data structure we're working with) as arguments. But we may
sometimes forget.
What if the way we implemented the search procedure looked something like this?
At a given stage in the search, we wouldn't just apply some function `f` to the
- head at this stage and the result accumulated so far, from folding the same
- function (and a base value) to the tail at this stage...and then pass the result
- of doing so leftward along the rest of the list.
+ head at this stage and the result accumulated so far (from folding the same
+ function, and a base value, to the tail at this stage)...and then pass the result
+ of that application to the embedding, more leftward computation.
- We'd *instead* give that function a "handler" that expected the result of the
- current stage *as an argument*, and evaluated to passing that result leftwards
- along the rest of the list.
+ We'd *instead* give `f` a "handler" that expects the result of the current
+ stage *as an argument*, and then evaluates to what you'd get by passing that
+ result leftwards up the list, as before.
Why would we do that, you say? Just more flamboyant lifting?
This "handler" encodes the search's having finished, and delivering a final
answer to whatever else you wanted your program to do with the result of the
search. If you like, at any stage in the search you might just give an argument
- to this handler, instead of giving an argument to the handler that continues
+ to *this* handler, instead of giving an argument to the handler that continues
the list traversal leftwards. Semantically, this would amount to *aborting* the
list traversal! (As we've said before, whether the rest of the list traversal
really gets evaluated will depend on what evaluation order is in place. But
f 3 <result of folding f and z over [2; 1]> <handler to continue folding leftwards> <handler to abort the traversal>
- `f`'s job would be to check whether 3 matches the element we're searching for
- (here also 3), and if it does, just evaluate to the result of passing `true` to
+ `f`'s job would be to check whether `3` matches the element we're searching for
+ (here also `3`), and if it does, just evaluate to the result of passing `true` to
the abort handler. If it doesn't, then evaluate to the result of passing
`false` to the continue-leftwards handler.
of the list multiplied to, because that would affect the answer you passed
along to the continue-leftwards handler.
- A **version 5** list would encode this kind of fold operation over the list, in
+ A **version 5** list encodes the kind of fold operation we're envisaging here, in
the same way that v3 (and v4) lists encoded the simpler fold operation.
Roughly, the list `[5;4;3;2;1]` would look like this:
\f z continue_leftwards_handler abort_handler.
- <fold f and z over [4; 3; 2; 1]>
+ <fold f and z over [4;3;2;1]>
(\result_of_fold_over_4321. f 5 result_of_fold_over_4321 continue_leftwards_handler abort_handler)
abort_handler
+ ; or, expanding the fold over [4;3;2;1]:
\f z continue_leftwards_handler abort_handler.
(\continue_leftwards_handler abort_handler.
- <fold f and z over [3; 2; 1]>
+ <fold f and z over [3;2;1]>
(\result_of_fold_over_321. f 4 result_of_fold_over_321 continue_leftwards_handler abort_handler)
abort_handler
)
(\result_of_fold_over_4321. f 5 result_of_fold_over_4321 continue_leftwards_handler abort_handler)
abort_handler
- and so on
+ ; and so on
Remarks: the `larger_computation_handler` should be supplied as both the
`continue_leftwards_handler` and the `abort_handler` for the leftmost