Types and Programming Languages Lecture 4 Simon Gay Department of Computing Science University of Glasgow 2006/07

Types and Programming Languages Lecture 4 - Simon Gay2 Variables We can easily extend the language of expressions to include variables. v ::= integer literal | true | false x ::= identifier e ::= v | x | e + e | e == e | e & e | if e then e else e We can form expressions such as x+1 or if x then y else 2 but what do they mean? If values (or perhaps expressions) are substituted for the variables then the resulting expression can be reduced. This sounds like function application…

2006/07Types and Programming Languages Lecture 4 - Simon Gay3 Typing expressions with variables We want to typecheck expressions like x+1 before substituting values for variables. We can say: if x:int then x+1:int and we write this as: In general: whereis the environment. is a typing judgement

2006/07Types and Programming Languages Lecture 4 - Simon Gay4 Typing expressions with variables The typing rules are as before, with the environment added: true : bool false : bool v : intif v is an integer literal (T-Plus)(T-And) (T-Eq)(T-If) and a rule for variables:, x:T x:T or (T-Var)

2006/07Types and Programming Languages Lecture 4 - Simon Gay5 Example: typing expressions with variables If =x:bool, y:int then we have the following derivation:

2006/07Types and Programming Languages Lecture 4 - Simon Gay6 Functions Define a syntax for function definitions: def ::= f(x:T,…,x:T):T is e f ::= identifier T ::= int | bool and extend the syntax of expressions to include function calls: e ::= v | x | e + e | e == e | e & e | if e then e else e | f(e,…,e)

2006/07Types and Programming Languages Lecture 4 - Simon Gay7 Functions To typecheck a function we need to know the types of its arguments and results, so well say that an environment contains typed variables x:T and function definitions Now we can define a typing rule for function application: (T-App)

2006/07Types and Programming Languages Lecture 4 - Simon Gay8 Functions We also need to typecheck a function definition, to make sure that the function body has the declared result type and uses the arguments according to their declared types. We introduce a new kind of judgement: and define a rule which specifies when a function definition is ok: (T-Def) This allows the function body e to refer to functions (including f ) defined in. So mutually recursive functions are allowed.

2006/07Types and Programming Languages Lecture 4 - Simon Gay9 Programs with functions Define a program to be a sequence of function definitions followed by a typed expression e:T. Let be the environment consisting of all the function definitions (and no variables). To typecheck a program: for each in, check that check that e:T. Then evaluate e (we need to define reductions for function applications).

2006/07Types and Programming Languages Lecture 4 - Simon Gay10 Program with functions: example f(x:int):int is if x==0 then 1 else x * f(x-1) f(5):int Assume that we include multiplication and subtraction in the obvious way: Exercises: What is the obvious way? What is when we typecheck this program? Show a complete derivation of

2006/07Types and Programming Languages Lecture 4 - Simon Gay11 Functions: operational semantics The idea is that a function applied to values reduces by substituting the values (actual parameters) for the arguments (formal parameters) in the function body. Substitution is defined recursively on the structure of terms: (R-App)

2006/07Types and Programming Languages Lecture 4 - Simon Gay12 Functions: operational semantics We also need rules defining reductions of function arguments: and so on. This is call by value semantics: function arguments are reduced to values before being substituted into the function body. Variables do not reduce: they are stuck. (Remember that we are only interested in evaluating expressions without variables.) (R-Arg1) (R-Arg2)

2006/07Types and Programming Languages Lecture 4 - Simon Gay13 Example f(x:int):int is if x==0 then 1 else x * f(x-1) f(5):int f(3) if 3==0 then 1 else 3*f(3-1) if false then 1 else 3*f(3-1) 3*f(3-1) 3*f(2) 3*(if 2==0 then 1 else 2*f(2-1)) 3*(if false then 1 else 2*f(2-1)) 3*2*f(2-1) 3*2*f(1) 3*2*(if 1==0 then 1 else 1*f(1-1)) 3*2*(if false then 1 else 1*f(1-1)) 3*2*1*f(1-1) 3*2*1*f(0) 3*2*1*(if 0==0 then 1 else 0*f(0-1)) 3*2*1*(if true then 1 else 0*f(0-1)) 3*2*1*1 3*2*1 3*2 6

2006/07Types and Programming Languages Lecture 4 - Simon Gay14 Type preservation Before proving the type preservation theorem, we need Substitution Lemma Ifand… then because otherwise we dont know anything about the type of and the proof of type preservation will break down when we get to the reduction of function applications.

2006/07Types and Programming Languages Lecture 4 - Simon Gay15 Proof of the Substitution Lemma By induction on the structure of e. Case 1. e is a value v. so v is an integer or boolean literal, T is either int or bool, and we havedirectly. Case 2. e is a variable, one of the and T is so we haveby assumption. Case 3. e is a variable x, not one of the and x must occur in so we have

2006/07Types and Programming Languages Lecture 4 - Simon Gay16 Proof of the Substitution Lemma Case 4. e is t+u (the other binary operators, and if, are similar) Using the induction hypothesis we have from which we can build which is what we want, because

2006/07Types and Programming Languages Lecture 4 - Simon Gay17 Proof of the Substitution Lemma Case 5. e is Using the induction hypothesis we have, for each i, from which we can build which is what we want, because

2006/07Types and Programming Languages Lecture 4 - Simon Gay18 Proof of the Substitution Lemma: Comment We would really like to be able to give a direct proof of the Substitution Lemma: in a derivation tree for replace every leaf by a derivation tree for to obtain a derivation tree for But this doesnt quite work because the environments get out of step. To do it properly we have to use proof by induction.

2006/07Types and Programming Languages Lecture 4 - Simon Gay19 Type Preservation Now that we have environments, we have Type Preservation Theorem If e:T and e e then e:T. Proof Similar to before, with a new base case for function application. and we assume that all function definitions are ok, so Given the reduction we know that

2006/07Types and Programming Languages Lecture 4 - Simon Gay20 Proof of Type Preservation We haveso, for each i, Now the Substitution Lemma tells us that as required. There are also new inductive cases corresponding to the rules for reducing function arguments, but these cases are similar to the corresponding cases for +.

2006/07Types and Programming Languages Lecture 4 - Simon Gay21 Typable stuck expressions are values The proof of this theorem is similar to before, but we have to deal with the case of variables, which are stuck. We do this by restricting attention to terms which contain no variables (recall that in a program we have e:T where only contains function definitions). Theorem If e:T and contains no variables and e is stuck then e is a value. Proof As before. The assumptions mean that e cannot be a variable.

2006/07Types and Programming Languages Lecture 4 - Simon Gay22 We have a Simple Functional Language The type system guarantees that computation does not get stuck. Its a call by value language. An alternative is call by name: and no reduction of function arguments. If we wanted to, we could allow function definitions to specify cbv or cbn for each argument. Real languages usually choose one or the other throughout. Haskell: call by name (lazy). ML: call by value (strict).

2006/07Types and Programming Languages Lecture 4 - Simon Gay23 Why is it so simple? Functions are not expressions. The only thing we can do with a function is apply it. This means that we do not need function types. We have a first order language. There are no nested functions. Function definitions occur only at the top level. However, we didnt simplify it all the way: working with named function definitions and allowing them to be recursive introduced some complications.

2006/07Types and Programming Languages Lecture 4 - Simon Gay24 Reading Pierce: 8 Exercises Pierce: 8.2.3, 8.3.4, 8.3.5, 8.3.6, 8.3.7, Exercise sheet 2 Section 2 of Linear Types for Packet Processing (again)