(no commit message)
[lambda.git] / topics / _week7_eval_cl.mdwn
index 2815817..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
-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
@@ -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?*
+
+
+[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.]