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

The Practice of Type Theory in Programming Languages

Robert Harper

Carnegie Mellon University

August, 2000

Acknowledgements

• Thanks to Reinhard Wilhelm for inviting me to speak!

• Thanks to my colleagues, former, and current students at Carnegie Mellon.

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.”

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.

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.

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.

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.

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

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.

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.

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).

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.

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.

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.

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

Typed Intermediate Languages

• Classical syntax-directed translation:Source = L1 L2 … Ln = Target

:

T1

• Type system applies to the source language only.– Type check, then throw away types.

Typed Intermediate Languages

• Type-directed translation:Source = L1 L2 … Ln = Target

: : :

T1 T2 … Tn

• Maintain types during compilation.– Translate a program and its type.– Types guide translation process.

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

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

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.

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

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

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

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.

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?

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!

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).

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”.

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.

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.

Further Information

http://www.typetheory.com