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

2. Types and Programming Languages Lecture 1 - Simon Gay2 Introduction Type definitions and declarations are essential aspects of high-level programming languages. Example (Java): class Example { int a; void set(int x) {a=x;} int get() {return a;} } Example e = new Example();

3. 2006/07Types and Programming Languages Lecture 1 - Simon Gay3 Compile-time (static) typechecking is standard 7.e.set(Hello); ^------------^ *** Semantic Error: No applicable overload for the method named set was found in type Example. Perhaps you wanted the overloaded version void set(int x); instead? 8.e.show(); ^------^ *** Semantic Error: No method named show was found in type Example. From the Jikes Java compiler (applied to some other code):

4. 2006/07Types and Programming Languages Lecture 1 - Simon Gay4 Compile-time (static) typechecking 9.i = e + 1; ^ *** Semantic Error: The type of this expression, Example, is not numeric.

5. 2006/07Types and Programming Languages Lecture 1 - Simon Gay5 Type declarations Organize data into high-level structures essential for high-level programming Document the program basic information about the meaning of variables and functions Inform the compiler example: how much storage each value needs Specify simple aspects of the behaviour of functions types as specifications is an important idea

6. 2006/07Types and Programming Languages Lecture 1 - Simon Gay6 Typechecking Static (compile-time) or dynamic (run-time) static is better: finds errors sooner, doesnt degrade performance (we will concentrate on static typechecking) Verifies that the programmers intentions (expressed by declarations) are observed by the program A program which typechecks is guaranteed to behave well at run-time at least: never apply an operation to the wrong type of value more: eg. security properties A program which typechecks respects the high-level abstractions eg: public/protected/private access in Java

7. 2006/07Types and Programming Languages Lecture 1 - Simon Gay7 Why study types (and programming languages)? The type system of a language has a strong effect on the feel of programming. Examples: In original Pascal, the result type of a function cannot be an array type. In Java, an array is just an object and arrays can be used anywhere. In Haskell, programming with lists is very easy; in Java it is much less natural. To understand a language fully, we need to understand its type system. We will see underlying typing concepts appearing in different languages in different ways, helping us to compare and understand language features.

8. 2006/07Types and Programming Languages Lecture 1 - Simon Gay8 Why study types (and programming languages)? How does a language designer (or a programmer) know that correctly-typed programs really have the desired run-time properties? To answer this question we need to see how to specify type systems, and how to prove that a type system is sound. To prove soundness we also need to specify the semantics (meaning) of programs - what happens when they are run. So studying types will lead us to a deeper understanding of the meaning of programs. Example of the issue of soundness: variant records in Pascal

9. 2006/07Types and Programming Languages Lecture 1 - Simon Gay9 Variant records in Pascal type kind = (staff,student); type person = record name : string; case k : kind of staff : (office : string) student : (year : integer) end; The following error cannot be detected by static typechecking: var simon : person; begin simon.name := Simon; simon.k := staff; simon.office := G093; write(simon.year + 5); end

10. 2006/07Types and Programming Languages Lecture 1 - Simon Gay10 Variant records in Ada type kind = (staff,student); type person(k : kind) is record name : String; case k is when staff => (office : String) when student => (year : Integer) end case; end record; Now we must declare simon : person(staff) and then simon.year is never allowed.

11. 2006/07Types and Programming Languages Lecture 1 - Simon Gay11 Possibilities and limitations of typechecking If types are specifications, can typechecking be used to verify program properties beyond correct use of data and functions? Yes, for example: secrecy and authenticity properties of security protocols behavioural properties (eg. deadlock-freedom) in concurrent systems But there are limits: most interesting properties cannot be automatically verified, even in principle, so types can only ever give a safe approximation to correctness. Also, in practice we want typechecking to be efficient.

12. 2006/07Types and Programming Languages Lecture 1 - Simon Gay12 Typechecking as a safe approximation For any static type system, and the notion of correctness which it aims to guarantee: It is essential that every typable program is correct. It is usually impossible to ensure that every correct program is typable. Typechecking must not accept any incorrect programs but always rejects some correct programs. Exercise: write down a fragment of Java code which will not typecheck but which, if executed, would not misuse any data.

13. 2006/07Types and Programming Languages Lecture 1 - Simon Gay13 Answer to exercise if (1 == 2) { int x = Hello * 5; } The Java typechecker assumes that every branch of a conditional statement may be executed (even if the condition is a compile-time constant or even a boolean literal). In general it is impossible to predict the value of an arbitrary expression at compile-time.

14. 2006/07Types and Programming Languages Lecture 1 - Simon Gay14 Principles Programming is difficult and we need all the automated help we can get! Static typechecking is one approach to program analysis. It has been enormously beneficial. Exact program analysis is impossible in general. Typechecking aims for limited guarantees of correctness, and inevitably rejects some correct programs. A type system restricts programming style, sometimes to an undesirable extent. The challenge in type system design: allow flexibility in programming, but not so much flexibility that incorrect programs can be expressed.

15. 2006/07Types and Programming Languages Lecture 1 - Simon Gay15 Why exact program analysis is impossible This is probably familiar from any course on computability… Some problems are undecidable - it is impossible to construct an algorithm which will solve arbitrary instances. The basic example is the Halting Problem: does a given program halt (terminate) when presented with a certain input? Problems involving exact prediction of program behaviour are generally undecidable, for example: does a program generate a run-time type error? does a program output the string Hello? We cant just run the program and see what happens, because there is no upper limit on the execution time of programs.

16. 2006/07Types and Programming Languages Lecture 1 - Simon Gay16 Undecidability of the Halting Problem (HP) Instance of HP: a legal program P and an input string S for P. Question: does P halt when run on S? Theorem: HP is undecidable Proof: by contradiction - we assume that we have an algorithm A that solves HP, and discover that the consequence of this assumption is a logical impossibility. Therefore the assumption must be false. Concretely, say P is a Java function: void P(String S); Let H be an implementation of algorithm A as a Java function: boolean H(String X, String S); Any language can be substituted for Java.

17. 2006/07Types and Programming Languages Lecture 1 - Simon Gay17 Undecidability of the Halting Problem (HP) Using H we can define a Java function Q: Q is given a legal Java function W Q uses H to determine whether or not W halts when given its own text as input if W halts then Q enters an infinite loop, otherwise Q halts void Q(String W) { if (H(W,W)) { while (true) {} }

18. 2006/07Types and Programming Languages Lecture 1 - Simon Gay18 Undecidability of the Halting Problem (HP) Now we run Q with its own text as input. What happens? Q(void Q(String W) {…}) Q calls H(Q,Q) which returns either true or false. If H returns true then: from the definition of H, Q halts on input Q. from the definition of Q, Q loops on input Q. CONTRADICTION! If H returns false then: from the definition of H, Q loops on input Q. from the definition of Q, Q halts on input Q. CONTRADICTION! Therefore Q cannot exist.

19. 2006/07Types and Programming Languages Lecture 1 - Simon Gay19 Consequences for program analysis The question Does program P generate a run-time type error with input S? is undecidable. If R were a decision procedure for this question then we could solve HP for program P by using R to analyse void NewP(String S) { P(S); int x = 1 + Hello; } because NewP generates a type error if and only if P halts. Similarly for any other behavioural property of programs.

20. 2006/07Types and Programming Languages Lecture 1 - Simon Gay20 All is not lost… This sounds rather bleak, but: static analysis (including type systems) is a huge and successful area incomplete analysis (remember: safe approximation) is better than no analysis, as long as not too many correct programs are ruled out A major trend in programming language development has been the inclusion of more sophisticated type systems in mainstream languages. By studying more powerful type systems, we can get a glimpse of what the next generation of languages might look like.

21. 2006/07Types and Programming Languages Lecture 1 - Simon Gay21 Administrative details Two lectures + one tutorial per week (Mon 11, Wed 9, Fri 10). Copies of presentations will be handed out. Some additional notes will be produced. There will be an assessed exercise (worth 20%) and an exam. A sample exam paper will be produced. I can be contacted by email (simon@dcs.gla.ac.uk), or in my office (G093) within reason. Books: Types and Programming Languages, B. C. Pierce compiler books Type Systems, L. Cardelli (material for reading course) Course web page:www.dcs.gla.ac.uk/~simon/teaching/tpl

22. 2006/07Types and Programming Languages Lecture 1 - Simon Gay22 Reading and Exercises Read Chapter 1 of Pierce. Refer to Chapter 2 of Pierce as necessary, during the rest of the course. For each hour of timetabled teaching you should expect to spend at least another hour on private study. After each lecture I will recommend reading from Pierces book; often I will also assign exercises from the book or from additional worksheets. During the tutorial sessions we can discuss any problems which arise from the reading or the exercises. For now: Read Sections 1 and 2 of Linear Types for Packet Processing.