(no commit message)
[lambda.git] / topics / _week7_eval_cl.mdwn
index 09a480b..102848d 100644 (file)
@@ -7,7 +7,7 @@
 We've discussed evaluation order before, primarily in connection with
 the untyped lambda calculus.  Whenever a term contains more than one
 redex, we have to choose which one to reduce, and this choice can make
 We've discussed evaluation order before, primarily in connection with
 the untyped lambda calculus.  Whenever a term contains more than one
 redex, we have to choose which one to reduce, and this choice can make
-a difference.  For instance, in the term `((\x.I)(ωω)`, if we reduce
+a difference.  For instance, in the term `((\x.I)(ωω))`, if we reduce
 the leftmost redex first, the term reduces to the normal form `I` in
 one step.  But if we reduce the left most redex instead (namely,
 `(ωω)`), we do not arrive at a normal form, and are in danger of
 the leftmost redex first, the term reduces to the normal form `I` in
 one step.  But if we reduce the left most redex instead (namely,
 `(ωω)`), we do not arrive at a normal form, and are in danger of
@@ -153,7 +153,7 @@ processing.  But just in case the result of the one-step reduction is
 itself a redex, we recursively call `reduce1`.  The recursion will
 continue until the result is no longer a redex.
 
 itself a redex, we recursively call `reduce1`.  The recursion will
 continue until the result is no longer a redex.
 
-    #trace reduce1;;
+    # #trace reduce1;;
     reduce1 is now traced.
     # reduce1 (FA (I, FA (I, K)));;
     reduce1 <-- FA (I, FA (I, K))
     reduce1 is now traced.
     # reduce1 (FA (I, FA (I, K)));;
     reduce1 <-- FA (I, FA (I, K))
@@ -351,3 +351,8 @@ this discussion:
 *How can we can we specify the evaluation order of a computational
 system in a way that is completely insensitive to the evaluation order
 of the specification language?*
 *How can we can we specify the evaluation order of a computational
 system in a way that is completely insensitive to the evaluation order
 of the specification language?*
+
+
+[By the way, the evaluators given here are absurdly inefficient computationally.
+Some computer scientists have trouble even looking at code this inefficient, but 
+the emphasis here is on getting the concepts across as simply as possible.]