References. ( pointers )

Size: px

Start display at page:

Download "References. ( pointers )"

Dayna Green
6 years ago
Views:

1 References ( pointers )

2 Basic Examples like C pointers r = ref 5!r r := 7 malloc *r *r = 7 (r:=succ(!r);!r) (r:=succ(!r); r:=succ(!r); r:=succ(!r); r:=succ(!r);!r)

3 Basic Examples i.e., r = ref 5!r r := 7 (r:=succ(!r);!r) (r:=succ(!r); r:=succ(!r); r:=succ(!r); r:=succ(!r);!r) ((((r:=succ(!r); r:=succ(!r)); r:=succ(!r)); r:=succ(!r));!r)

4 Aliasing A value of type Ref T is a pointer to a cell holding a value of type T. r = 5 If this value is copied by assigning it to another variable, the cell pointed to is not copied. r = s = 5 So we can change r by assigning to s: (s:=6;!r)

5 Aliasing all around us Reference cells are not the only language feature that introduces the possibility of aliasing. I arrays I communication channels I I/O devices (disks, etc.)

6 The di culties of aliasing The possibility of aliasing invalidates all sorts of useful forms of reasoning about programs, both by programmers... The function r:ref Nat. s:ref Nat. (r:=2; s:=3;!r) always returns 2 unless r and s are aliases....and by compilers: Code motion out of loops, common subexpression elimination, allocation of variables to registers, and detection of uninitialized variables all depend upon the compiler knowing which objects a load or a store operation could reference. High-performance compilers spend significant energy on alias analysis to try to establish when di erent variables cannot possibly refer to the same storage.

7 The benefits of aliasing The problems of aliasing have led some language designers simply to disallow it (e.g., Haskell). But there are good reasons why most languages do provide constructs involving aliasing: I e ciency (e.g., arrays) I action at a distance (e.g., symbol tables) I shared resources (e.g., locks) in concurrent systems I etc.

8 Example c = ref 0 incc = x:unit. (c := succ (!c);!c) ++c decc = x:unit. (c := pred (!c);!c) incc unit decc unit o = {i = incc, d = decc} Q: how about c++?

9 let newcounter = _:Unit. let c = ref 0 in let incc = x:unit. (c := succ (!c);!c) in let decc = x:unit. (c := pred (!c);!c) in let o = {i = incc, d = decc} in o

10 Syntax t ::= terms unit unit constant x variable x:t.t abstraction t t application ref t reference creation!t dereference t:=t assignment... plus other familiar types, in examples.

11 Typing Rules ` t 1 : T 1 ` ref t 1 : Ref T 1 (T-Ref) ` t 1 : Ref T 1 `!t 1 : T 1 (T-Deref) ` t 1 : Ref T 1 ` t 2 : T 1 ` t 1 :=t 2 : Unit (T-Assign)

12 Final example NatArray = Ref (Nat!Nat); newarray = _:Unit. ref ( n:nat.0); : Unit! NatArray lookup = a:natarray. n:nat. (!a) n; : NatArray! Nat! Nat update = a:natarray. m:nat. v:nat. let oldf =!a in a := ( n:nat. if equal m n then v else oldf n); : NatArray! Nat! Nat! Unit

13 Evaluation What is the value of the expression ref 0?

14 Evaluation What is the value of the expression ref 0? Crucial observation: evaluating ref 0 must do something. Otherwise, and r = ref 0 s = ref 0 r = ref 0 s = r would behave the same.

15 Evaluation What is the value of the expression ref 0? Crucial observation: evaluating ref 0 must do something. Otherwise, and r = ref 0 s = ref 0 r = ref 0 s = r would behave the same. Specifically, evaluating ref 0 should allocate some storage and yield a reference (or pointer) to that storage.

16 Evaluation What is the value of the expression ref 0? Crucial observation: evaluating ref 0 must do something. Otherwise, and r = ref 0 s = ref 0 r = ref 0 s = r would behave the same. Specifically, evaluating ref 0 should allocate some storage and yield a reference (or pointer) to that storage. So what is a reference?

17 The Store A reference names a location in the store (also known as the heap or just the memory). What is the store?

18 The Store A reference names a location in the store (also known as the heap or just the memory). What is the store? I Concretely: An array of 8-bit bytes, indexed by 32-bit integers.

19 The Store A reference names a location in the store (also known as the heap or just the memory). What is the store? I Concretely: An array of 8-bit bytes, indexed by 32-bit integers. I More abstractly: an array of values

20 The Store A reference names a location in the store (also known as the heap or just the memory). What is the store? I Concretely: An array of 8-bit bytes, indexed by 32-bit integers. I More abstractly: an array of values I Even more abstractly: a partial function from locations to values.

21 Locations Syntax of values: v ::= values unit unit constant x:t.t abstraction value l store location... and since all values are terms...

22 Syntax of Terms t ::= terms unit unit constant x variable x:t.t abstraction t t application ref t reference creation!t dereference t:=t assignment l store location

23 Aside Does this mean we are going to allow programmers to write explicit locations in their programs?? No: This is just a modeling trick. We are enriching the source language to include some run-time structures, so that we can continue to formalize evaluation as a relation between source terms. Aside: If we formalize evaluation in the big-step style, then we can add locations to the set of values (results of evaluation) without adding them to the set of terms.

24 Evaluation The result of evaluating a term now depends on the store in which it is evaluated. Moreover, the result of evaluating a term is not just a value we must also keep track of the changes that get made to the store. I.e., the evaluation relation should now map a term and a store to a reduced term and a new store. t µ! t 0 µ 0 We use the metavariable µ to range over stores.

25 Evaluation An assignment t 1 :=t 2 first evaluates t 1 and t 2 until they become values... t 1 µ! t 0 1 µ0 t 1 :=t 2 µ! t 0 1 :=t 2 µ 0 (E-Assign1) t 2 µ! t 0 2 µ0 v 1 :=t 2 µ! v 1 :=t 0 2 µ0 (E-Assign2)... and then returns unit and updates the store: l:=v 2 µ! unit [l 7! v 2 ]µ (E-Assign)

26 A term of the form ref t 1 first evaluates inside t 1 until it becomes a value... t 1 µ! t 0 1 µ0 ref t 1 µ! ref t 0 1 µ0 (E-Ref)... and then chooses (allocates) a fresh location l, augments the store with a binding from l to v 1, and returns l: l /2 dom(µ) ref v 1 µ! l (µ, l 7! v 1 ) (E-RefV) p = malloc(...)

27 A term!t 1 first evaluates in t 1 until it becomes a value... t 1 µ! t 0 1 µ0!t 1 µ!!t 0 1 µ0 (E-Deref)... and then looks up this value (which must be a location, if the original term was well typed) and returns its contents in the current store: µ(l) =v!l µ! v µ (E-DerefLoc)

28 Evaluation rules for function abstraction and application are augmented with stores, but don t do anything with them directly. t 1 µ! t 0 1 µ0 t 1 t 2 µ! t 0 1 t 2 µ 0 (E-App1) t 2 µ! t 0 2 µ0 v 1 t 2 µ! v 1 t 0 2 µ0 (E-App2) ( x:t 11.t 12 ) v 2 µ! [x 7! v 2 ]t 12 µ (E-AppAbs)

29 Aside: garbage collection Note that we are not modeling garbage collection the store just grows without bound.

30 Aside: pointer arithmetic We can t do any!

31 Store Typings

32 Typing Locations Q: What is the type of a location?

33 Typing Locations Q: What is the type of a location? A: It depends on the store! E.g., in the store (l 1 7! unit, l 2 7! unit), the term!l 2 has type Unit. But in the store (l 1 7! unit, l 2 7! type Unit!Unit. x:unit.x), the term!l 2 has

34 Typing Locations first try Roughly: ` µ(l) : T 1 ` l : Ref T 1

35 Typing Locations first try Roughly: More precisely: ` µ(l) : T 1 ` l : Ref T 1 µ ` µ(l) : T 1 µ ` l : Ref T 1 I.e., typing is now a four-place relation (between contexts, stores, terms, and types).

36 Problem However, this rule is not completely satisfactory. For one thing, it can make typing derivations very large! E.g., if (µ = l 1 7! x:nat. 999, l 2 7! x:nat.!l 1 (!l 1 x), l 3 7! x:nat.!l 2 (!l 2 x), l 4 7! x:nat.!l 3 (!l 3 x), l 5 7! x:nat.!l 4 (!l 4 x)), then how big is the typing derivation for!l 5?

37 Problem! But wait... it gets worse. Suppose (µ = l 1 7! x:nat.!l 2 x, l 2 7! x:nat.!l 1 x), Now how big is the typing derivation for!l 2?

38 Store Typings Observation: The typing rules we have chosen for references guarantee that a given location in the store is always used to hold values of the same type. These intended types can be collected into a store typing a partial function from locations to types.

39 E.g., for µ =(l 1 7! x:nat. 999, l 2 7! x:nat.!l 1 (!l 1 x), l 3 7! x:nat.!l 2 (!l 2 x), l 4 7! x:nat.!l 3 (!l 3 x), l 5 7! x:nat.!l 4 (!l 4 x)), A reasonable store typing would be =(l 1 7! Nat!Nat, l 2 7! Nat!Nat, l 3 7! Nat!Nat, l 4 7! Nat!Nat, l 5 7! Nat!Nat)

40 Now, suppose we are given a store typing describing the store µ in which we intend to evaluate some term t. Then we can use to look up the types of locations in t instead of calculating them from the values in µ. (l) =T 1 ` l : Ref T 1 (T-Loc) I.e., typing is now a four-place relation between between contexts, store typings, terms, and types.

41 Final typing rules (l) =T 1 ` l : Ref T 1 (T-Loc) ` t 1 : T 1 ` ref t 1 : Ref T 1 (T-Ref) ` t 1 : Ref T 11 `!t 1 : T 11 (T-Deref) ` t 1 : Ref T 11 ` t 2 : T 11 ` t 1 :=t 2 : Unit (T-Assign)

42 Q: Where do these store typings come from?

43 Q: Where do these store typings come from? A: When we first typecheck a program, there will be no explicit locations, so we can use an empty store typing. So, when a new location is created during evaluation, l /2 dom(µ) ref v 1 µ! l (µ, l 7! v 1 ) (E-RefV) we can observe the type of v 1 and extend the current store typing appropriately.

44 Safety

45 Preservation First attempt: just add stores and store typings in the appropriate places. Theorem (?): If ` t : T and t µ! t 0 µ 0, then ` t 0 : T.

46 Preservation First attempt: just add stores and store typings in the appropriate places. Theorem (?): If ` t : T and t µ! t 0 µ 0, then ` t 0 : T. Wrong! Why is this wrong?

47 Preservation First attempt: just add stores and store typings in the appropriate places. Theorem (?): If ` t : T and t µ! t 0 µ 0, then ` t 0 : T. Wrong! Why is this wrong? Because and µ here are not constrained to have anything to do with each other! (Exercise: Construct an example that breaks this statement of preservation.)

48 Preservation A store µ is said to be well typed with respect to a typing context and a store typing, written ` µ, if dom(µ) =dom( ) and ` µ(l) : (l) for every l 2 dom(µ).

49 Preservation A store µ is said to be well typed with respect to a typing context and a store typing, written ` µ, if dom(µ) =dom( ) and ` µ(l) : (l) for every l 2 dom(µ). Next attempt: Theorem (?): If ` t : T t µ! t 0 µ 0 ` µ then ` t 0 : T.

50 Preservation A store µ is said to be well typed with respect to a typing context and a store typing, written ` µ, if dom(µ) =dom( ) and ` µ(l) : (l) for every l 2 dom(µ). Next attempt: Theorem (?): If ` t : T t µ! t 0 µ 0 ` µ then ` t 0 : T. Still wrong! What s wrong now?

51 Preservation A store µ is said to be well typed with respect to a typing context and a store typing, written ` µ, if dom(µ) =dom( ) and ` µ(l) : (l) for every l 2 dom(µ). Next attempt: Theorem (?): If ` t : T t µ! t 0 µ 0 ` µ then ` t 0 : T. Still wrong! Creation of a new reference cell... l /2 dom(µ) ref v 1 µ! l (µ, l 7! v 1 ) (E-RefV)... breaks the correspondence between the store typing and the store.

52 Preservation (correct version) Theorem: If ` t : T ` µ t µ! t 0 µ 0 then, for some 0, 0 ` t 0 : T 0 ` µ 0.

53 Preservation (correct version) Theorem: If ` t : T ` µ t µ! t 0 µ 0 then, for some 0, 0 ` t 0 : T 0 ` µ 0. Proof: Easy extension of the preservation proof for!.

54 Progress Theorem: Suppose t is a closed, well-typed term (that is, ; ` t : T for some T and ). Then either t is a value or else, for any store µ such that ; ` µ, there is some term t 0 and store µ 0 with t µ! t 0 µ 0.

Type Systems Winter Semester 2006

Type Systems Winter Semester 2006 Week 9 December 13 December 13, 2006 - version 1.0 Plan PREVIOUSLY: unit, sequencing, let, pairs, sums TODAY: 1. recursion 2. state 3.??? NEXT: exceptions? NEXT: polymorphic