fix comment about forcing eval order
authorJim Pryor <profjim@jimpryor.net>
Sat, 16 Oct 2010 15:52:34 +0000 (11:52 -0400)
committerJim Pryor <profjim@jimpryor.net>
Sat, 16 Oct 2010 15:52:34 +0000 (11:52 -0400)
Signed-off-by: Jim Pryor <profjim@jimpryor.net>
week4.mdwn

index 49a2c1f..ab4411f 100644 (file)
@@ -520,12 +520,11 @@ but really all we're in a position to mean by that are claims about the result
 of the complex expression semantically depending only on this, not on that. A
 demon evaluator who custom-picked the evaluation order to make things maximally
 bad for you could ensure that all the semantically unnecessary computations got
 of the complex expression semantically depending only on this, not on that. A
 demon evaluator who custom-picked the evaluation order to make things maximally
 bad for you could ensure that all the semantically unnecessary computations got
-evaluated anyway. We don't have any way to prevent that. Later,
-we'll see ways to *semantically guarantee* one evaluation order rather than
-another. Though even then the demonic evaluation-order-chooser could make it
-take unnecessarily long to compute the semantically guaranteed result. Of
-course, in any real computing environment you'll know you're dealing with a
-fixed evaluation order and you'll be able to program efficiently around that.
+evaluated anyway. We don't yet know any way to prevent that. Later, we'll see
+ways to *semantically guarantee* one evaluation order rather than another. Of
+course, in any real computing environment you'll know in advance that you're
+dealing with a fixed evaluation order and you'll be able to program efficiently
+around that.
 
 In detail, then, here's what our v5 lists will look like:
 
 
 In detail, then, here's what our v5 lists will look like: