week9 tweak
[lambda.git] / week9.mdwn
index dbabb6d..9c886b0 100644 (file)
@@ -100,6 +100,8 @@ Scheme is similar. There are various sorts of reference cells available in Schem
                (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.)
+
 When dealing with explicit-style mutation, there's a difference between the types and values of `ycell` and `!ycell` (or `(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.
 
 
@@ -224,7 +226,27 @@ Notice in these fragments that once we return from inside the call to `factory`,
 
 ##Referential opacity##
 
-In addition to order-sensitivity, when you're dealing with mutable variables you also give up a property that computer scientists call "referential transparency." It's not obvious whether they mean exactly the same by that as philosophers and linguists do, or only something approximately the same. What they do mean is a kind of substitution principle, illustrated here:
+In addition to order-sensitivity, when you're dealing with mutable variables you also give up a property that computer scientists call "referential transparency." It's not obvious whether they mean exactly the same by that as philosophers and linguists do, or only something approximately the same.
+
+The core idea to referential transparency is that when the same value is supplied to a context, the whole should always evaluate the same way. Mutation makes it possible to violate this. Consider:
+
+       let ycell = ref 1
+               in let f x = x + !ycell
+                       in let first = f 1      (* first is assigned the value 2 *)
+                               in ycell := 2; let second = f 1 (* second is assigned the value 3 *)
+                                       in first = second;; (* not true! *)
+
+Notice that the two invocations of `f 1` yield different results, even though the same value is being supplied as an argument to the same function.
+
+Similarly, functions like these:
+
+       let f cell = !cell;;
+
+       let g cell = cell := !cell + 1; !cell;;
+
+may return different results each time they're invoked, even if they're always supplied one and the same reference cell as argument.
+
+Computer scientists also associate referential transparency with a kind of substitution principle, illustrated here:
 
        let x = 1
                in (x, x)
@@ -249,6 +271,8 @@ Notice, however, that when mutable variables are present, the same substitution
        (* then creates a *new* ref 1 cell and returns *its* contents *)
 
 
+
+
 ##How to implement explicit-style mutable variables##
 
 We'll think about how to implement explicit-style mutation first. We suppose that we add some new syntactic forms to a language, let's call them `newref`, `deref`, and `setref`. And now we want to expand the semantics for the language so as to interpret these new forms.
@@ -501,6 +525,9 @@ To get the whole process started, the complex computation so defined will need t
     Notice: h, p have same value (1), but f (h, p) and f (h, h) differ
 
 
+Fine and Pryor on "coordinated contents" (see, e.g., [Hyper-Evaluativity](http://www.jimpryor.net/research/papers/Hyper-Evaluativity.txt))
+
+
 ##Five grades of mutation involvement##
 
 -- FIXME --
@@ -564,7 +591,29 @@ To get the whole process started, the complex computation so defined will need t
        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.
 
 
+##Offsite Reading##
+
+*      [[!wikipedia Declarative programming]]
+*      [[!wikipedia Functional programming]]
+*      [[!wikipedia Purely functional]]
+*      [[!wikipedia Side effect (computer science) desc="Side effects"]]
+*      [[!wikipedia Referential transparency (computer science)]]
+*      [[!wikipedia Imperative programming]]
+*      [[!wikipedia Reference (computer science) desc="References"]]
+*      [[!wikipedia Pointer (computing) desc="Pointers"]]
+*      [Pointers in OCaml](http://caml.inria.fr/resources/doc/guides/pointers.html)
+
 <!--
-Fine and Pryor on "coordinated contents" (see, e.g., [Hyper-Evaluativity](http://www.jimpryor.net/research/papers/Hyper-Evaluativity.txt))
+# General issues about variables and scope in programming languages #
+
+*      [[!wikipedia Variable (programming) desc="Variables"]]
+*      [[!wikipedia Free variables and bound variables]]
+*      [[!wikipedia Variable shadowing]]
+*      [[!wikipedia Name binding]]
+*      [[!wikipedia Name resolution]]
+*      [[!wikipedia Parameter (computer science) desc="Function parameters"]]
+*      [[!wikipedia Scope (programming) desc="Variable scope"]]
+*      [[!wikipedia Closure (computer science) desc="Closures"]]
+
 -->