1. The Practice of Type Theory in Programming Languages Robert Harper Carnegie Mellon University August, 2000

2. Acknowledgements Thanks to Reinhard Wilhelm for inviting me to speak! Thanks to my colleagues, former, and current students at Carnegie Mellon.

3. An Old Story Once upon a time (es war einmal), there were those who thought that typed high-level programming languages would save the world. –Ensure safety of executed code. –Support reasoning and verification. –Run efficiently (enough) on stock hardware. “If we all programmed in Pascal (or Algol or Simula or …), all of our problems would be solved.”

4. What Happened Instead Things didn’t worked out quite as expected or predicted. –COTS software is mostly written in low- level, unsafe languages (ie, C, C++) –Some ideas have been adopted (eg, objects and classes), most haven’t. –Developers have learned to work with less- than-perfect languages, achieving astonishing results.

5. Languages Ride Again But the world has changed: strong safety assurances are more important than ever. –Mobile code on the internet. –Increasing reliance on software in “real life”. Schneider made a strong case for language- based security mechanisms. –“Languages aren’t just languages any more.” –Rich body of work on logics, semantics, type systems, verification, compilation.

6. Language-Based Security Key idea: program analysis is more powerful than execution monitoring. This talk is about one approach to taking this view seriously, typed certifying compilation.

7. Type Theory and Languages Type theory has emerged as the central organizing principle for language … –Design: genericity, abstraction, and modularity mechanisms. –Implementation: type inference, flow analysis. –Semantics: domain theory, logical relations.

8. What is a Type System? A type system is a syntactic discipline for enforcing levels of abstraction. –Ensures that bad things do not happen. A type system rules out programs. –Adding a function to a string –Interpreting an integer as a pointer –Violating interfaces

9. What is a Type System? How can this be a good thing? –Expressiveness arises from strictures: restrictions entail stronger invariants –Flexibility arises from controlled relaxation of strictures, not from their absence. A type system is fundamentally a verification tool that suffices to ensure invariants on execution behavior.

10. Types Induce Invariants Types induce invariants on programs. –If e : int, then its value must be an integer. –If e : int  int, then it must be a function taking and yielding integers. –If e : filedesc, then it must have been obtained by a call to open. –If e : int{H}, then no “low clearance” expression can read its value.

11. Types Induce Invariants These invariants provide –Safety properties: well-typed programs do not “go wrong”. –Equational properties: when are two expressions interchangeable in all contexts. –Representation independence (parametricity).

12. Types as Safety Certificates Typing is a sufficient condition for these invariants to hold. –Well-typed implies well-behaved. –Not (necessarily) checkable at run-time! Types form a certificate of safety. –Type checking = safety checking. –A practical sufficient condition for safety.

13. The HLL Assumption This is well and good, but … –Programs are compiled to unsafe, low-level machine code. –We want to know that the object code is safe. HLL assumption: trust the correctness of the compiler and run-time system. –A huge assumption. –Spurred much research in compiler correctness.

14. Certifying Compilers Idea: propagate types from the source to the object code. –Can be checked by a code recipient. –Avoids reliance on compiler correctness. Based on a new approach to compilation. –Typed intermediate languages. –Type-directed translation.

15. Typed Intermediate Languages Generalize syntax-directed translation to type-directed translation. –intermediate languages come equipped with a type system. –compiler transformations translate both a program and its type. –translation preserves typing: if e:T then e*:T* after translation

16. Typed Intermediate Languages Classical syntax-directed translation: Source = L 1  L 2  …  L n = Target : T 1 Type system applies to the source language only. –Type check, then throw away types.

17. Typed Intermediate Languages Type-directed translation: Source = L 1  L 2  …  L n = Target : : : T 1  T 2  …  T n Maintain types during compilation. –Translate a program and its type. –Types guide translation process.

18. Typed Closure Conversion The type S  T becomes the ADT type Env val env : Env val code : Env * S -> T The application F(a) becomes call(F.code,(F.env, a)) Functions are implementations of the ADT. –Essentially, functions are represented as objects. –Environment = private fields, code = method.

19. Typed Object Code Typed Assembly Language (TAL) –type information ensures safety –generated by compiler –very close to standard x86 assembly Type information captures –types of registers and stack –type assumptions at branch targets (including join points) Relies heavily on polymorphism! –eg, callee-saves registers, enforcing abstraction

20. Typed Assembly Language fact: ALL rho.{r1:int, sp:{r1:int, sp:rho}::rho} jgz r1, positive mov r1,1 ret positive: push r1 ; sp : int::{t1:int,sp:rho}::rho sub r1,r1,1 call fact[int::{r1:int,sp:rho}::rho] imul r1,r1,r2 pop r2 ; sp : {r1:int,sp:rho}:: ret

21. Tracking Stronger Properties Familiar type systems go a long way. –Ensures minimal sanity of code. –Ensures compliance with interfaces. –Especially if you have polymorphism. Refinement types take a step further. –Track value range invariants. –Array bounds checks, null pointer checks, red-black invariants, etc.

22. Refinement Types First idea: subset types. e : { x : T | P(x) } iff e:T and |= P(e) Examples: –Pascal-like sub-ranges 0..n = { n : int | 0  n < length(A) } –Non-null objects –Red-black condition on RBT’s

23. Refinement types Checking value range properties is undecidable! –eg, cannot decide if 0  e < 10 for general expressions e Checker must include a theorem prover to validate object code. –either complex and error prone, or –too weak to be useful

24. Refinement Types Second idea: proof carrying code. (e,  ) : { x:T | P(x) } iff e:T and  |- P(e) Provide a proof of the range property. –How to obtain it? –How to represent it? Verifier checks the types and the proof. –using a proof checker, not a proof finder

25. Finding Proofs To use A[n] safely, we must prove that 0  n  size(A). If we insert a run-time check, it’s easy! –if 0  n  size(A) then *(A+4n) else fail In general we must find proofs. –Instrumented analysis methods. –Programmer declarations.

26. Representing Proofs How do we represent the proofs? –Need a formal logic for reasoning about value range properties (for example). –Need a proof checker for each such formalism. But which logic should we use? –How do we accommodate change? –Which properties are of interest?

27. Logical Frameworks The LF logical framework is a universal language for defining logical systems. –Captures uniformities of a large class of logical systems. –Provides a formal definition language for logical systems. Proof checking is reduced to a very simple form of type checking. –One type checker yields many proof checkers!

28. Logical Frameworks Specify the syntactic categories as LF types: term : type. formula : type. proof : formula -> type. For each formula, there is a type of proofs of that formula in the logic.

29. Logical Frameworks Specify generators of each category: zero : term. succ : term -> term. implies : formula -> formula. modus_ponens : proof (implies A B) -> proof A -> proof B. Validity checking = type checking!

30. General Certified Code The logic is part of the safety certificate! –Logic of type safety. –Logic of value ranges. –Logic of space requirements. Proofs are LF terms for that logic. –Checker is parameterized on specification of the logic (an LF “signature”). –LF type checker checks proofs in any logic (provided it is formalized in LF).

31. Some Challenges Can certified compilation really be made practical? –TALC [Morrisett] for “safe C”. –TILT [CMU] for Standard ML [in progress]. –SML/NJ [Yale] for Standard ML [in progress]. –Touchstone [Necula, Lee] for “safe C”.

32. Some Challenges Can refinements be made useful and practical? –Dependent ML [Pfenning, Xi] –Dependently-Typed Assembly [Harper, Xi] Experience with ESC is highly relevant. –A difference is that refinements are built in to the language.

33. Some Predictions Certifying compilation will be standard technology. –Code will come equipped with checkable safety certificates. Type systems will become the framework for building practical development tools. –Part of the program text. –Mechanically checkable.

34. Further Information http://www.typetheory.com