X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=miscellaneous_lambda_challenges_and_advanced_topics.mdwn;h=0342fc64fcbbff3396aa304a4d5948670b671ba1;hp=d9f1c40058b9a369809101d4aab142ef7eb6b0db;hb=a23765ce50e30e655255b3eb24db91d4582cb68a;hpb=c41011d1b721965659468bfae6105c054e0c257b diff --git a/miscellaneous_lambda_challenges_and_advanced_topics.mdwn b/miscellaneous_lambda_challenges_and_advanced_topics.mdwn index d9f1c400..0342fc64 100644 --- a/miscellaneous_lambda_challenges_and_advanced_topics.mdwn +++ b/miscellaneous_lambda_challenges_and_advanced_topics.mdwn @@ -254,13 +254,13 @@ can use. to get the first element of the pair. Of course you can lift that if you want: -
extract_1st ≡ \pair. pair (\x y. x)
+ extract_fst ≡ \pair. pair (\x y. x)
but at a lower level, the pair is still accepting its handler as an argument,
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.
@@ -303,13 +303,13 @@ can use.
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?
@@ -324,7 +324,7 @@ can use.
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
@@ -339,8 +339,8 @@ can use.
f 3