week9 tweak

[lambda.git] / week9.mdwn

diff --git a/week9.mdwn b/week9.mdwn
index a7b3278..2e80250 100644 (file)
--- a/week9.mdwn
+++ b/week9.mdwn
@@ -100,7 +100,13 @@ Scheme is similar. There are various sorts of reference cells available in Schem
                (set-box! ycell 3)
                (+ x (unbox ycell)))
 
                (set-box! ycell 3)
                (+ x (unbox ycell)))
 

-(C has explicit-style mutable variables, too, which it calls *pointers*. But simple variables in C are already mutable, in the implicit style.)
+C has explicit-style mutable variables, too, which it calls *pointers*. But simple variables in C are already mutable, in the implicit style. Scheme also has both styles of mutation. In addition to the explicit boxes, Scheme also lets you mutate unboxed variables:
+
+       (begin
+               (define x 1)
+               (set! x 2)
+               x)
+       ; evaluates to 2

 
 When dealing with explicit-style mutation, there's a difference between the types and values of `ycell` and `!ycell` (or in Scheme, `(unbox ycell)`). The former has the type `int ref`: the variable `ycell` is assigned a reference cell that contains an `int`. The latter has the type `int`, and has whatever value is now stored in the relevant reference cell. In an implicit-style framework though, we only have the resources to refer to the contents of the relevant reference cell. `y` in fragment [G] or the C snippet above has the type `int`, and only ever evaluates to `int` values.
 
 
 When dealing with explicit-style mutation, there's a difference between the types and values of `ycell` and `!ycell` (or in Scheme, `(unbox ycell)`). The former has the type `int ref`: the variable `ycell` is assigned a reference cell that contains an `int`. The latter has the type `int`, and has whatever value is now stored in the relevant reference cell. In an implicit-style framework though, we only have the resources to refer to the contents of the relevant reference cell. `y` in fragment [G] or the C snippet above has the type `int`, and only ever evaluates to `int` values.
 


@@ -669,7 +675,7 @@ Programming languages tend to provide a bunch of mutation-related capabilities a
                in let (adder', setter') = factory 1
                in ...
 
                in let (adder', setter') = factory 1
                in ...
 

-       Of course, in most languages you wouldn't be able to evaluate a comparison like `getter = getter'`, because in general the question whether two computations always return the same values for the same argument is not decidable. So typically languages don't even try to answer that question. However, it would still be true that `getter` and `getter'` (and `adder` and `adder'`) were extensionally equivalent.
+       Of course, in most languages you wouldn't be able to evaluate a comparison like `getter = getter'`, because in general the question whether two functions always return the same values for the same arguments is not decidable. So typically languages don't even try to answer that question. However, it would still be true that `getter` and `getter'` (and `adder` and `adder'`) were extensionally equivalent.

 
        However, they're not numerically identical, because by calling `setter 2` (but not calling `setter' 2`) we can mutate the function value `getter` (and `adder`) so that it's *no longer* qualitatively indiscernible from `getter'` (or `adder'`).
 
 
        However, they're not numerically identical, because by calling `setter 2` (but not calling `setter' 2`) we can mutate the function value `getter` (and `adder`) so that it's *no longer* qualitatively indiscernible from `getter'` (or `adder'`).