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?