X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=topics%2F_week7_eval_cl.mdwn;h=4d1b3e761f43ef083dd06b6ff00dbd4a0829e5c4;hb=8dc497d55a7d1931fc916246506eac923e7a7188;hp=85dbef532366cfa7052f7d1664d8fb19ae8b0fdb;hpb=9f05abffbfea36163962acfb1471ab0b6c45b036;p=lambda.git

diff --git a/topics/_week7_eval_cl.mdwn b/topics/_week7_eval_cl.mdwn
index 85dbef53..4d1b3e76 100644
--- a/topics/_week7_eval_cl.mdwn
+++ b/topics/_week7_eval_cl.mdwn
@@ -17,14 +17,13 @@ recall that
 
 There are two redexes in this term; we've marked the operative lambdas
 with a star.  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
+to the normal form `I` in one step.  But if we reduce the rightmost
 redex instead, the "reduced" form is `(\x.I)Ω` again, and we are in
 danger of entering an infinite loop.
 
-Thanks to the recent introduction of sum types (disjoint union), we
+Thanks to the introduction of sum types (disjoint union) in the last lecture, we
 are now in a position to gain a deeper understanding of evaluation
-order by reasoning explicitly about evaluation by writing a program
-that evaluates terms.
+order by writing a program that allows us to reasoning explicitly about evaluation.
 
 One thing we'll see is that it is all too easy for the evaluation
 order properties of an evaluator to depend on the evaluation order