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

Types and Programming Languages Lecture 11 - Simon Gay2 Type Systems for Resource Control We will now look at how type systems used to control not only how data is used but also how many times it is used: in other words, regarding data as a resource. Examples: If we know that the object x will be used exactly once, then after its first use the allocated memory can be reclaimed: compile-time garbage collection. In a lazy language function parameters are evaluated on demand. If we know that f uses its parameter at least once, then we can use call by value, saving the overhead of implementing laziness.

2006/07Types and Programming Languages Lecture 11 - Simon Gay3 Type Systems for Resource Control Examples: In “Linear Types for Packet Processing”, the aim is to ensure that each packet is owned by just one thread. In programming languages for quantum computation, it is important to treat quantum data as a resource: it is not physically possible to duplicate an unknown quantum state. There are type systems which statically control the sequence of operations on a file or other OS resource: e.g. a file must be opened before writing to it. This only works if the resource has a unique owner.

2006/07Types and Programming Languages Lecture 11 - Simon Gay4 Linear Types First we’ll look at a type system in which each value is used exactly once. This is called linear typing. Examples: x.x will be typable x.1 will not be typable x.(x+x) will not be typable Pure linearity is a very severe restriction, and we will see how to make the system more flexible later. and x. y. x and x.(x+2)

2006/07Types and Programming Languages Lecture 11 - Simon Gay5 Linear Types Considering the examples on the previous slide, how can we modify the typing rules of lambda calculus to get this effect?   true : bool   false : bool   v : intif v is an integer literal These rules allow x:T, y:U  v : int in which variables are not used. But we don’t need an environment to type a constant.  true : bool  false : bool  v : intif v is an integer literal STANDARD LINEAR

2006/07Types and Programming Languages Lecture 11 - Simon Gay6 Linear Types This rule allows x:T, y:U  x : T in which variables are not used. But we don’t need extra variables in the environment. STANDARD LINEAR (T-Var) (L-Var) x : T  x : T

2006/07Types and Programming Languages Lecture 11 - Simon Gay7 Linear Types Now we have to think carefully about rules with more than one hypothesis. We want to allow but not Solution: rules of the form LINEAR where  and  must be disjoint and ,  means union.

2006/07Types and Programming Languages Lecture 11 - Simon Gay8 Linear Types Conditional expressions also require careful thought. if c then t else e evaluates either t or e. The only way to consistently describe the exact assumptions of this expression is if t and e use the same resources. L-If LINEAR Using these ideas we can complete the typing rules. Function application is similar to other binary operators. Abstraction is the same as before. It is common to use the symbol –o for linear function type.

2006/07Types and Programming Languages Lecture 11 - Simon Gay9 Lambda Calculus with Linear Types  true : bool  false : bool  v : intif v is an integer literal (L-Plus)(L-And) (L-Eq)(L-If) (L-Abs) (L-App) (L-Var) x : T  x : T

2006/07Types and Programming Languages Lecture 11 - Simon Gay10 Exercises 1.Show complete typing derivations for the following expressions in linear typed lambda calculus: x:int. f:int –o int. f(x) x:int. y:int. z:int. if x==y then z else z+1 How do they differ from typing derivations for the same expressions in simply typed lambda calculus? 2. Prove that if   e:T is derivable in linear typed lambda calculus then it is also derivable in simply typed lambda calculus.

2006/07Types and Programming Languages Lecture 11 - Simon Gay11 Operational Semantics The operational semantics of the lambda calculus with linear types is exactly the same as for the untyped lambda calculus. We have restricted the set of valid expressions, but those expressions which are valid execute in the same way as before. This is an example of one language with two different type systems, designed for different purposes.

2006/07Types and Programming Languages Lecture 11 - Simon Gay12 Type Safety: No Runtime Errors If we are interested in the absence of runtime errors, as before, then we can use a very simple argument to prove that a typed expression of the linear typed lambda calculus executes with no errors. If   e:T in the linear typed lambda calculus then we also have   e:T in the simply typed lambda calculus. Because the operational semantics is the same, we know that e executes without errors. But we want more: the purpose of the linear type system is to guarantee that resources are used exactly once, so we would like to prove that this is the case. We will look at this later.

2006/07Types and Programming Languages Lecture 11 - Simon Gay13 Typechecking with Linear Types A typical linear typing rule such as is not directly suitable for implementation in a typechecker. Reading the rule upwards, we have to guess how to split the given environment into  and . If we are asked to check  ’  e+f : int then how do we work out what  and  should be in order to build a derivation?  should be just the environment needed for e, and  should be the rest. While typechecking we have to examine the structure of e, so we can calculate  at the same time.

2006/07Types and Programming Languages Lecture 11 - Simon Gay14 Typechecking with Linear Types We can formulate the typechecking algorithm as inference rules for a new form of judgement:   e : T   ’ Given  and e, we calculate T and  ’  ’ is the part of  which is not needed in order to type e. Examples: x:int, y:bool  x : int  y:bool x:int, y:int  x+y : int   x:int, y:bool  1 : int  x:int, y:bool

2006/07Types and Programming Languages Lecture 11 - Simon Gay15 Typechecking with Linear Types   true : bool     false : bool     v : int   if v is an integer literal (LT-Plus) (LT-If) (L-Abs) (L-App) (LT-Var) , x : T,  ’  x : T  ,  ’ similarly &, ==

2006/07Types and Programming Languages Lecture 11 - Simon Gay16 Typechecking with Linear Types We want every value to be used exactly once, which means checking that the whole environment is used. To establish   e : T we check that   e : T   i.e. we run the typechecking algorithm and check that the final environment returned is empty. Examples Exercise: convert any of our typecheckers to a linear type system.

2006/07Types and Programming Languages Lecture 11 - Simon Gay17 Correctness of Linear Typechecking We now have two different inference systems. One is the original definition of the linear type system, and the other claims to be a typechecking algorithm. We should check that they agree. It is possible to prove:   e : T   if and only if   e : T Left to right: soundness of the typechecking algorithm Right to left: completeness of typechecking algorithm Proving this is a little complex; we need to prove a suitable generalisation (   e : T   is not strong enough as the I.H.).

2006/07Types and Programming Languages Lecture 11 - Simon Gay18 Beyond Pure Linearity A purely linear type system is very restrictive and in practice we need to regain the full power of lambda calculus. Now that the principles of linear typing are well understood, it is straightforward to combine linear and standard type constructors. The main point to be careful of is that a standard data structure must never contain linear data.