X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=week9.mdwn;h=2b80483989efca1fd91845b1a022eee173b2ee36;hp=7028e8925c428bc47d009908eb84189477630cfb;hb=40b5ff7bf5c1f0fe0843ca938af8ced1ec5c9976;hpb=76d9f4e25744b644758a4e359048f3a16f8ea8c4

diff --git a/week9.mdwn b/week9.mdwn
index 7028e892..2b804839 100644
--- a/week9.mdwn
+++ b/week9.mdwn
@@ -291,7 +291,11 @@ Now we're going to relativize our interpretations not only to the assignment fun
 
 >	\[[expression]]<sub>g s</sub> = (value, s')
 
-For expressions we already know how to interpret, `s'` will usually just be `s`. One exception is complex expressions like `let var = expr1 in expr2`. Part of interpreting this will be to interpret the sub-expression `expr1`, and we have to allow that in doing that, the store may have already been updated. We want to use that possibly updated store when interpreting `expr2`. Like this:
+For expressions we already know how to interpret, expect `s'` to just be `s`.
+An exception is complex expressions like `let var = expr1 in expr2`. Part of
+interpreting this will be to interpret the sub-expression `expr1`, and we have
+to allow that in doing that, the store may have already been updated. We want
+to use that possibly updated store when interpreting `expr2`. Like this:
 
 	let rec eval expression g s =
 		match expression with
@@ -304,6 +308,15 @@ For expressions we already know how to interpret, `s'` will usually just be `s`.
 			eval expr2 ((c, value) :: g) s'
 		...
 
+Similarly:
+
+		...
+		| Addition (expr1, expr2) ->
+			let (value1, s') = eval expr1 g s
+			in let (value2, s'') = eval expr2 g s'
+			in (value1 + value2, s'')
+		...
+
 Let's consider how to interpet our new syntactic forms `newref`, `deref`, and `setref`: