comment on handout/alias/let
[lambda.git] / week9.mdwn
index 363b5d9..cf59820 100644 (file)
@@ -326,7 +326,7 @@ Similarly:
 Let's consider how to interpet our new syntactic forms `newref`, `deref`, and `setref`:
 
 
-1.     **newref starting_val** 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 ...
@@ -429,6 +429,8 @@ Here's how to implement these. We'll suppose that our assignment function is lis
                        (* evaluate expr2 using original assignment function and new store *)
                        in eval expr2 g s''
 
+Note: Chris uses this kind of machinery on the third page of the Nov 22 handout. Except he implements `Let` the way we here implement `Change`. And he adds an implementation of `Alias` (see below). Some minor differences: on his handout (and following Groenendijk, Stockhof and Veltman), he uses `r` and `g` where we use `g` and `s` respectively. Also, he implements his `r` with a function from `char` to `int`, instead of a `(char * int) list`, as we do here. It should be obvious how to translate between these. His implementation requires that variables always already have an associated peg. So that when we call `Let(c, expr1, expr2)` for the first time with `c`, there's a peg whose value is to be updated. That's easier to ensure when you implement the assignment as a function than as a `(char * int) list`.
+
 
 ##How to implement mutation with a State monad##
 
@@ -730,6 +732,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##