Coursehero >> New York >> Cornell >> CS 611

Course Hero has millions of student submitted documents similar to the one below including study guides, homework solutions, papers, exam answer keys and textbook solutions.

Lecture CS611 14 State and mutable variables 23 September 2007 Lecturer: Andrew Myers 1 Some thoughts about state State refers to the ability to have mutation: a change in value over time. The functional languages we have studied so far, such as the -calculus and uML, have not had state, in the sense that once a value is created, it is impossible to change that value, and once a variable is bound it cannot be rebound to a new value (except by creating a new variable). Although state is not a necessary feature of a programming language (e.g. -calculus is Turing complete but does not have a notion of state), it is a feature of most languages in common use today. We distinguish between functional languages and imperative languages primarily on the basis of whether they are organized primarily around a stateless paradigm (with higher-order functions), or an stateful paradigm of mutable variables and data structures. It might be more useful, in fact, to distinguish between stateless and stateful languages, since stateful languages usually have functions too. Why do many programmers like stateful programming languages? Perhaps because it matches how we think of the world. We view the world as being composed of entities (such as people or objects) with intrinsic unchanging identities. These entities change their state over time while maintaining the same underlying identity. If a programming language matches our mental model of the world, it s more comfortable for programmers to think about. Thus, stateful languages always come equipped with an underlying notion of identity, such as variable identity or object identity. In these languages, the binding between identities and their current states can change over time. Stateful languages intrinsically have a notion of time, unlike pure functional languages such as uML or lambda calculus, which take an essentially timeless view of computation. In stateless languages, it doesn t matter exactly when something happens, because the outcome will be the same regardless. In stateful languages with multiple concurrent threads, it matters a great deal when something happens. It can be argued that our perception of underlying identity is an illusion. In physics, identity does not exist: particles are identi ed by their state, not by any intrinsic identity. If two electrons in di erent states are swapped, no change has happened to the universe, because an electron is really the same thing as its state. Time is arguably an illusion as well: the universe is a multidimensional object in which physics says that time is much more symmetric to the other dimensions than we perceive. Being made of particles ourselves, we are only able to sense a single moment in time. Arguably, the universe is purely functional, and our minds deceive us. In fact, the idea that we are deceived into thinking that objects have an underlying identity dates back to Buddhist and even earlier Vedantic philosophy (the Upanishads). The mismatch between reality and our perceptions becomes pragmatically relevant when we look at the di culties in programming multiprocessor/multicore systems. Our consciousness is single-threaded, so it makes perfect sense to us to think about state evolving along a single timeline. But when with multiple simultaneous threads of computation, and communication delays, it is infeasible to give all threads a single, consistent view of the state evolution of the system. We nd it very di cult to reason about how such multithreaded systems work and to write correct programs for them in a stateful language. Designing workable programming languages for multicore systems is currently an active research topic. In sidestepping the intrinsic problems with state, a stateless language may be a better match for such systems than the stateful languages we commonly use! 2 First-class references We extend uML with state, and call the new language uML! . We use a construct called a reference cell that allows a value to be rebound to di erent values over time. We can then use reference cells to model language features such as mutable variables. Reference cells are rst-class values in this language, like in ML. The syntax of uML! is as follows: 1 e ::= | | | | ... ref e !e e1 := e2 e1 ; e2 (create a reference cell with initial value from e) (evaluation or dereference) (assignment or mutation) (sequential composition) Informally, the meaning of these new expressions is as follows. Evaluating the expression ref e creates a new reference cell having the initial value e. The expression !e evaluates to the current value of the reference cell e. The assignment e1 := e2 assigns the value of e2 to the reference cell e1 , and in our semantics returns the value null. Other design choices could have been made. For example, the assignment operator could have returned the value of e2 so that expressions like e0 := (e1 := e2 ) would make sense and could be used to assign the same value to multiple variables. In this treatment, reference cells are rst-class objects. This is more powerful than simple mutable variables as in C. It is also more dangerous, because it introduces aliasing, as the following example demonstrates: let x = ref 1 in let y = x in let z = (x := 2) in !y Here y is an alias for x. Dereferencing y gives us the value of x, which in this case has changed from 1 to 2. The expression therefore evaluates to 2. In other words, if you kick x, y jumps! Aliasing is a constant source of errors in stateful programming. A classic example is a procedure that is supposed to multiply two matrices a and b and write the result imperatively into a third matrix c. The programmer writes the obvious code, then later wants to set a to the product of a and b. This makes the matrix multiply compute something completely di erent from what was intended, and is very hard to debug! 2.1 Operational semantics We now give an operational semantics for reference cell expressions in uML! . To do this, we de ne a con guration as a pair e, , where e is an expression and is a function mapping reference cells to values. Reference cells are denoted generically by . We extend the grammar of expressions and values to include reference cells. e ::= . . . | v ::= . . . | We inherit the existing reductions from uML, lifting them to apply to uML! expressions. All these reductions have no side e ects, so the state is unchanged by them: e e e, uML! e , ref v, := v, ! , null; e, , [v ] null, [v ] ( ), e, (where (where (where dom( )) / dom( )) dom( )) 2 where [v ] is the same function as , except that the value on input is changed to v. The language has eager, left-to-right evaluation, so the evaluation contexts are given by this grammar: E ::= . . . | ref E | ! E | E := e | := E | E; e The structural congruence rule is adapted to take into account the current state: e, e , E[ e ], E[ e ], 2.2 Translation semantics [[e]] is an expression that computes a pair (e , ) in a naming environment and state , where e is the resulting expression and is the store. [[n]] [[x]] [[if eb then e1 else e2 ]] [[ref e]] [[ !e]] [[e1 := e2 ]] = (n, ) = ( x , ) = let (b, )1 = [[eb ]] in if b then [[e1 ]] else [[e2 ]] = let (x, ) = [[e]] in MALLOC x = let (x, ) = [[e]] in (LOOKUP x, ) = let (x1 , ) 1 = [[e1 ]] in let (x2 , 2 ) = [[e2 ]] 1 in (null, UPDATE 2 x1 x2 ) = let (x, 1 ) = [[e1 ]] in [[e2 ]] 1 = (null, ) = let (y, ) = [[e1 ]] in [[e2 ]](EXTEND x y) = y dyn . [[e]] (EXTEND lex x y) dyn = let (f, 1 ) = [[e1 ]] dyn dyn in let (v, 2 ) = [[e2 ]] dyn 1 in f v 2 [[e1 ; e2 ]] [[null]] [[let x = e1 in e2 ]] [[ x. e]] lex lex [[e1 e2 ]] dyn dyn Here, we rely on certain abbreviations (MALLOC, UPDATE, and LOOKUP), for manipulating stores. The function MALLOC allocates a new memory location; LOOKUP reads the contents of a memory location; UPDATE produces a new store with one location changed. Further, we will need an initial store EMPTY-STORE. We don t care exactly how these terms are implemented, as long as they obey certain equations (the notion of equality here is equivalence after evaluation): LOOKUP EMPTY-STORE = error LOOKUP (#1 (MALLOC v)) = error LOOKUP (#2 (MALLOC v)) (#1 (MALLOC v)) = v LOOKUP (#2 (MALLOC v)) = LOOKUP LOOKUP (UPDATE v) = v LOOKUP (UPDATE v) = LOOKUP (if = #1 (MALLOC v)) (if = ) Implementing terms with these properties is left as an exercise to the reader. 1 let (b, ) = [[eb ]] in e here is syntactic sugar for let p = [[eb ]] in let b = #1 p in let = #2 p in e . 3 3 Mutable variables Let s take a closer look at what happens in a language like C, where variables themselves are mutable. 3.1 Syntax e ::= . . . uML . . . | e1 = e2 | e | &e | e1 ; e2 where we think of the constructs respectively as: e1 = e2 is assignment where e1 is an assignable variable name, for instance, an array reference. e is used to dereference a pointer e (acts sort of like ! in UML! ). &e gives a pointer to the location of e. 3.2 Translation semantics The target language is again uML. Since variables are mutable, we need to change the naming environment to be a mapping from variable names to store locations. Each variable is bound to the identity of its reference cell. The translation we de ne takes into account the fact that C has two kinds of values: lvalues, values which can appear in the left-hand side of an assignment; and rvalues, values that cannot appear on the LHS. To capture this in the target language, for each expression e of C, we de ne [[e]]L (the lvalue of e) and [[e]]R (the rvalue of e). As before, we need to keep track of the state of the computation so the results of the translations are pairs. To summarize: [[e]]L = (location of e, ) [[e]]R = (value of e, ). The translation is de ned inductively on the structure of C programs. Note that some lvalue translations are not de ned, corresponding to invalid expressions that a C compiler would catch. For instance, [[n]]L is not de ned. This prevents reassigning of, say, the integer 5 to have the value 3. [[n]]R [[x]]L [[e]]R For assignment: [[e1 = e2 ]]R Comments: This forces left-to-right evaluation. It allows a chain of assignments. For example, e1 = e2 = e3 = e4 = 5 will assign 5 to each ei in our translation, just as in C. 4 = let( , ) = [[e1 ]]L in let(v, ) = [[e2 ]]R in (v, UPDATE = (n, ) = ( x , ) = let ( , ) = [[e]]L in (LOOKUP , ) (if [[e]]L is de ned) v) An assignment statement is not an lvalue in C, nor is it here. Addressing: [[ e]]L [[&e]]R = = [[e]]R [[e]]L So the two operations, , &, are inverses of each other; their function is to shift the view of a value rather than to do computation. For example, the semantics de ned above let us write & & &x = 2. This will have the same e ect as x = 2. Another example (written in C): int y = 0; int x = &y; *x = 1; This piece of code assigns 1 to y. Note that it would be illegal to include a line &y = 0x1002; because we can t change the address of a variable. Functions: [[ x.e]]R [[e1 e2 ]]R Discussion: Choices we made: function applications don t a ect state, in function application use left to right evaluation. In de ning function application, the allocation is required because variables must be bound to locations, whereas the argument of the function is a value (C is call-by-value). The value that a function returns is an rvalue rather than an lvalue. Why? Returning an lvalue whould mean we could assign new values to locations allocated during computation, e.g. bo 5 = 1;. We choose a semantics where we get back the value of a computation rather than its location. Note that we do not need to explicitly de ne the store in the translation of function application because f v returns a pair of a location and a store. = y dyn . let ( , ) = MALLOC dyn y in [[e]]R (EXTEND x ) , = let (f, ) = [[e1 ]]R in let (v, ) = [[e2 ]]R in f v 4 Pass (call) by Reference It is conceivable to de ne a language where arguments to functions are lvalues. In this case, the body of functions can update the argument and therefore change the value stored in the location passed in. Examples of such languages are PASCAL, MODULA, Ada, Matlab (sort of), FORTRAN. Consider a simple syntax for pass-by-reference: e ::= . . . | r x. e | rcall e1 e2 Note that we are explicitly saying when we pass by reference because we do not have a type system that distinguishes between the two cases. Example program: let let x = 1 in f = r y. y = y + 1 in rcall f x 5 In this program, y is an alias for x, so the value at the location of x is updated to 2. To incorporate pass-by-reference into the semantics, we just need to change the rules for functions: [[ r x.e]]R [[rcall e1 e2 ]]R = y dyn .[[e]]R (EXTEND x y) dyn , = let (f, ) = [[e1 ]]R in let ( , ) = [[e2 ]]L in f Since we are given a location, we don t need to allocate new memory. 5 Objects 5.1 De nition Objects combine naming and the notion of state. We can think of objects as naming environments. For instance, we might have: class C int x; int y; int m (int z) . . . x . . . y . . . this . . . z ; where x, y are elds (which are mutable) and m is a method ( immutable). Each of the elds and methods may be public or private, and the class itself might be mentioned using the keyword this This is reminiscent of modules (recall: modules are non-hierarchical scope which introduces names that may or may not be accessible outside the scope). Let s try to encode objects using module constructs: e ::= . . . uML . . . | ( elds x1 = e1 , . . . , xn = en ; methods f1 = y1 .e1 , . . . , fm = ym .em ) | e.x where the rst new clause de nes the object and the second clause selects components of the object. 5.2 Translation We will translate objects to a naming environment. [[( elds = e, methods f = y.e )]] = x let z = [[e]] in Y( . x . if x = x1 then z1 else if x = x2 then z2 else . . . if x = f1 then z1 .[[e1 ]](EXTEND (EXTEND y z1 ) this ) . . .) Note that we used the Y combinator to allow method bodies to talk about the object itself, i.e. the naming environment de ned by the object. 5.3 Problem Objects as recursive records breaks when we try to implement inheritance, because the name this is bound in the methods of the super-object to the wrong xed point. 6

Find millions of documents here - Study Guides, Homework Solutions, Papers, Exam Answer Keys and more. Course Hero has millions of course related materials that will enable you to learn better, faster and get an A in all your courses.
Below is a small sample set of documents: