go back and read week1
[lambda.git] / week9.mdwn
index 7554c3d..d659e75 100644 (file)
@@ -326,7 +326,7 @@ Similarly:
 Let's consider how to interpet our new syntactic forms `newref`, `deref`, and `setref`:
 
 
-1.     When `expr` evaluates to starting\_val, **newref expr** should allocate a new reference cell in the store and insert `starting_val` into that cell. It should return some "key" or "index" or "pointer" to the newly created reference cell, so that we can do things like:
+1.     When `expr` evaluates to `starting_val`, **newref expr** should allocate a new reference cell in the store and insert `starting_val` into that cell. It should return some "key" or "index" or "pointer" to the newly created reference cell, so that we can do things like:
 
                let ycell = newref 1
                in ...
@@ -730,6 +730,11 @@ Programming languages tend to provide a bunch of mutation-related capabilities a
 
        We use the `None`/`Some factorial` option type here just as a way to ensure that the contents of `fact_cell` are of the same type both at the start and the end of the block.
 
+*      Now would be a good time to go back and review some material from [[week1]], and seeing how much we've learned. There's discussion back then of declarative or functional languages versus languages using imperatival features, like mutation. Mutation is distinguished from shadowing. There's discussion of sequencing, and of what we mean by saying "order matters."
+
+In point 7 of the Rosetta Stone discussion, the contrast between call-by-name and call-by-value evaluation order appears (though we don't yet call it that). We'll be discussing that more in coming weeks. In the [[damn]] example, continuations and other kinds of side-effects (namely, printing) make an appearance. These too will be center-stage in coming weeks.
+
 
 ##Offsite Reading##