Simply-Typed Lambda Calculus

Similar documents
Simply-Typed Lambda Calculus

More Lambda Calculus and Intro to Type Systems

More Lambda Calculus and Intro to Type Systems

More Lambda Calculus and Intro to Type Systems

Programming Languages

Type Systems. Today. 1. Organizational Matters. 1. Organizational Matters. Lecture 1 Oct. 20th, 2004 Sebastian Maneth. 1. Organizational Matters

CS-XXX: Graduate Programming Languages. Lecture 9 Simply Typed Lambda Calculus. Dan Grossman 2012

COS 320. Compiling Techniques

1 Introduction. 3 Syntax

Semantic Analysis and Type Checking

Programming Languages Lecture 14: Sum, Product, Recursive Types

In Our Last Exciting Episode

CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011

Programming Languages Fall 2014

Harvard School of Engineering and Applied Sciences Computer Science 152

Recursive Types and Subtyping

Com S 541. Programming Languages I

Types for References, Exceptions and Continuations. Review of Subtyping. Γ e:τ τ <:σ Γ e:σ. Annoucements. How s the midterm going?

Programming Languages. Programming with λ-calculus. Lecture 11: Type Systems. Special Hour to discuss HW? if-then-else int

Goal. CS152: Programming Languages. Lecture 15 Parametric Polymorphism. What the Library Likes. What The Client Likes. Start simpler.

Costly software bugs that could have been averted with type checking

Recursive Types and Subtyping

CS558 Programming Languages

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End

CSCE 314 Programming Languages. Type System

Second-Order Type Systems

Programming Languages Lecture 15: Recursive Types & Subtyping

CS558 Programming Languages

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

Type Systems. Pierce Ch. 3, 8, 11, 15 CSE

CS 565: Programming Languages. Spring 2008 Tu, Th: 16:30-17:45 Room LWSN 1106

The role of semantic analysis in a compiler

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

Lecture 9: More Lambda Calculus / Types

- M ::= v (M M) λv. M - Impure versions add constants, but not necessary! - Turing-complete. - true = λ u. λ v. u. - false = λ u. λ v.

CMSC 330: Organization of Programming Languages. Operational Semantics

Pierce Ch. 3, 8, 11, 15. Type Systems

COMP 1130 Lambda Calculus. based on slides by Jeff Foster, U Maryland

Mutable References. Chapter 1

Type Inference. Prof. Clarkson Fall Today s music: Cool, Calm, and Collected by The Rolling Stones

Lecture 5: The Untyped λ-calculus

Programming Languages Third Edition. Chapter 7 Basic Semantics

CSCI-GA Scripting Languages

CMSC 330: Organization of Programming Languages

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

Formal Systems and their Applications

Chapter 13: Reference. Why reference Typing Evaluation Store Typings Safety Notes

CIS 500 Software Foundations Fall October 2

Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness?

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

At build time, not application time. Types serve as statically checkable invariants.

Concepts of Programming Languages

G Programming Languages - Fall 2012

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

Programming Language Concepts: Lecture 19

Operational Semantics. One-Slide Summary. Lecture Outline

Outline. Introduction Concepts and terminology The case for static typing. Implementing a static type system Basic typing relations Adding context

Polymorphic lambda calculus Princ. of Progr. Languages (and Extended ) The University of Birmingham. c Uday Reddy

We defined congruence rules that determine the order of evaluation, using the following evaluation

CMSC 330: Organization of Programming Languages

Types and Type Inference

1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.

Denotational Semantics. Domain Theory

Introduction to System F. Lecture 18 CS 565 4/20/09

CSE 505: Programming Languages. Lecture 10 Types. Zach Tatlock Winter 2015

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Type Checking and Type Inference

CS558 Programming Languages

Programming Languages 2nd edition Tucker and Noonan"

CMSC330. Objects, Functional Programming, and lambda calculus

CS 242. Fundamentals. Reading: See last slide

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming

CS 4110 Programming Languages & Logics. Lecture 17 Programming in the λ-calculus

Today s Class. Programming Languages Topic of Ultimate Mastery. Reasonable Initial Skepticism. Meta-Level Information

Topics Covered Thus Far. CMSC 330: Organization of Programming Languages. Language Features Covered Thus Far. Programming Languages Revisited

COSE212: Programming Languages. Lecture 3 Functional Programming in OCaml

Programmiersprachen (Programming Languages)

Compilers and computer architecture: Semantic analysis

CMSC 330: Organization of Programming Languages. Lambda Calculus

Introduction to ML. Mooly Sagiv. Cornell CS 3110 Data Structures and Functional Programming

Type Systems, Type Inference, and Polymorphism

Functional Programming

Writing Evaluators MIF08. Laure Gonnord

Lecture 7: Type Systems and Symbol Tables. CS 540 George Mason University

Dependant Type Systems (saying what you are) Data Abstraction (hiding what you are) Review. Dependent Types. Dependent Type Notation

Functional Programming. Big Picture. Design of Programming Languages

CSC312 Principles of Programming Languages : Functional Programming Language. Copyright 2006 The McGraw-Hill Companies, Inc.

Programming Languages, Summary CSC419; Odelia Schwartz

(Advanced) topics in Programming Languages

Functional Programming

CMSC 336: Type Systems for Programming Languages Lecture 5: Simply Typed Lambda Calculus Acar & Ahmed January 24, 2008

Typed Lambda Calculus and Exception Handling

CS 415 Midterm Exam Spring 2002

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Notation. The rules. Evaluation Rules So Far.

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far

Transcription:

#1 Simply-Typed Lambda Calculus

#2 Back to School What is operational semantics? When would you use contextual (small-step) semantics? What is denotational semantics? What is axiomatic semantics? What is a verification condition?

#3 Today s (Short?) Cunning Plan Type System Overview First-Order Type Systems Typing Rules Typing Derivations Type Safety

#4 Types A program variable can assume a range of values during the execution of a program An upper bound of such a range is called a type of the variable A variable of type bool is supposed to assume only boolean values If x has type bool then the boolean expression not(x) has a sensible meaning during every run of the program

#5 Typed and Untyped Languages Untyped languages Do not restrict the range of values for a given variable Operations might be applied to inappropriate arguments. The behavior in such cases might be unspecified The pure λ-calculus is an extreme case of an untyped language (however, its behavior is completely specified) (Statically) Typed languages Variables are assigned (non-trivial) types A type system keeps track of types Types might or might not appear in the program itself Languages can be explicitly typed or implicitly typed

#6 The Purpose Of Types The foremost purpose of types is to prevent certain types of run-time execution errors Traditional trapped execution errors Cause the computation to stop immediately And are thus well-specified behavior Usually enforced by hardware e.g., Division by zero, floating point op with a NaN e.g., Dereferencing the address 0 (on most systems) Untrapped execution errors Behavior is unspecified (depends on the state of the machine = this is very bad!) e.g., accessing past the end of an array e.g., jumping to an address in the data segment

#7 Execution Errors A program is deemed safe if it does not cause untrapped errors Languages in which all programs are safe are safe languages For a given language we can designate a set of forbidden errors A superset of the untrapped errors, usually including some trapped errors as well e.g., null pointer dereference Modern Type System Powers: prevent race conditions (e.g., Flanagan TLDI 05) prevent insecure information flow (e.g., Li POPL 05) prevent resource leaks (e.g., Vault, Weimer) help with generic programming, probabilistic languages, are often combined with dynamic analyses (e.g., CCured)

#8 Preventing Forbidden Errors - Static Checking Forbidden errors can be caught by a combination of static and run-time checking Static checking Detects errors early, before testing Types provide the necessary static information for static checking e.g., ML, Modula-3, Java Detecting certain errors statically is undecidable in most languages

#9 Preventing Forbidden Errors - Dynamic Checking Required when static checking is undecidable e.g., array-bounds checking Run-time encodings of types are still used (e.g. Lisp) Should be limited since it delays the manifestation of errors Can be done in hardware (e.g. null-pointer)

#10 Why Typed Languages? Development Type checking catches early many mistakes Reduced debugging time Typed signatures are a powerful basis for design Typed signatures enable separate compilation Maintenance Types act as checked specifications Types can enforce abstraction Execution Static checking reduces the need for dynamic checking Safe languages are easier to analyze statically the compiler can generate better code

Why Not Typed Languages? Static type checking imposes constraints on the programmer Some valid programs might be rejected But often they can be made well-typed easily Hard to step outside the language (e.g. OO programming in a non-oo language, but cf. Ruby, OCaml, etc.) Dynamic safety checks can be costly 50% is a possible cost of bounds-checking in a tight loop In practice, the overall cost is much smaller Memory management must be automatic ) need a garbage collector with the associated run-time costs Some applications are justified in using weakly-typed languages (e.g., by external safety proof) #11

#12 Safe Languages There are typed languages that are not safe ( weakly typed languages ) All safe languages use types (static or dynamic) Safe Unsafe Static ML, Java, Ada, C#, Haskell,... C, C++, Pascal,... Typed Dynamic Lisp, Scheme, Ruby, Perl, Smalltalk, PHP, Python, We focus on statically typed languages? Untyped λ-calculus Assembly

#13 Properties of Type Systems How do types differ from other program annotations? Types are more precise than comments Types are more easily mechanizable than program specifications Expected properties of type systems: Types should be enforceable Types should be checkable algorithmically Typing rules should be transparent Should be easy to see why a program is not well-typed

#14 Why Formal Type Systems? Many typed languages have informal descriptions of the type systems (e.g., in language reference manuals) A fair amount of careful analysis is required to avoid false claims of type safety A formal presentation of a type system is a precise specification of the type checker And allows formal proofs of type safety But even informal knowledge of the principles of type systems help

#15 Formalizing a Language 1. Syntax Of expressions (programs) Of types Issues of binding and scoping 2. Static semantics (typing rules) Define the typing judgment and its derivation rules 3. Dynamic Semantics (e.g., operational) Define the evaluation judgment and its derivation rules 4. Type soundness Relates the static and dynamic semantics State and prove the soundness theorem

Typing Judgments Judgment (recall) A statement J about certain formal entities Has a truth value ² J Has a derivation ` J (= a proof ) A common form of typing judgment: Γ ` e : τ (e is an expression and τ is a type) Γ (Gamma) is a set of type assignments for the free variables of e Defined by the grammar Γ ::= Γ, x : τ Type assignments for variables not free in e are not relevant e.g, x : int, y : int ` x + y : int #16

#17 Typing rules Typing rules are used to derive typing judgments Examples:

#18 Typing Derivations A typing derivation is a derivation of a typing judgment (big surprise there ) Example: We say Γ ` e : τ to mean there exists a derivation of this typing judgment (= we can prove it ) Type checking: given Γ, e and τ find a derivation Type inference: given Γ and e, find τ and a derivation

Proving Type Soundness A typing judgment is either true or false Define what it means for a value to have a type v 2 k τ k (e.g. 5 2 k int k and true 2 k bool k ) Define what it means for an expression to have a type e 2 j τ j iff 8v. (e v ) v 2 k τ k) Prove type soundness If ` e : τ or equivalently If ` e : τ and e v then e 2 j τ j then v 2 k τ k This implies safe execution (since the result of a unsafe execution is not in k τ k for any τ) #19

#20 Upcoming Exciting Episodes We will give formal description of first-order type systems (no type variables) Function types (simply typed λ-calculus) Simple types (integers and booleans) Structured types (products and sums) Imperative types (references and exceptions) Recursive types (linked lists and trees) The type systems of most common languages are first-order Then we move to second-order type systems Polymorphism and abstract types

Q: Movies (378 / 842) This 1988 animated movie written and directed by Isao Takahata for Studio Ghibli was considered by Roger Ebert to be one of the most powerful anti-war films ever made. It features Seita and his sister Setsuko and their efforts to survive outside of society during the firebombing of Tokyo.

Computer Science This American-Canadian Turing-award winner is known for major contributions to the fields of complexity theory and proof complexity. He is known for formalizing the polynomial-time reduction, NP-completeness, P vs. NP, and showing that SAT is NP-complete. This was all done in the seminal 1971 paper The Complexity of Theorem Proving Procedures.

Q: Games (504 / 842) This 1985 falling-blocks computer game was invented by Alexey Pajitnov (Алексей Пажитнов) and inspired by pentominoes.

Simply-Typed Lambda Calculus Notice :τ Syntax: Terms e ::= x λx:τ. e e 1 e 2 n e 1 + e 2 iszero e true false not e if e 1 then e 2 else e 3 Types τ ::= int bool τ 1! τ 2 τ 1! τ 2 is the function type! associates to the right Arguments have typing annotations :τ This language is also called F 1 #24

#25 Static Semantics of F 1 The typing judgment Γ ` e : τ Some (simpler) typing rules:

#26 More Static Semantics of F 1 Why do we have this mysterious gap? I don t know either!

#27 Typing Derivation in F 1 Consider the term λx : int. λb : bool. if b then f x else x With the initial typing assignment f : int! Int Where Γ = f : int! int, x : int, b : bool

#28 Type Checking in F 1 Type checking is easy because Typing rules are syntax directed Typing rules are compositional (what does this mean?) All local variables are annotated with types In fact, type inference is also easy for F 1 Without type annotations an expression may have no unique type ` λx. x : int! int ` λx. x : bool! bool

#29 Operational Semantics of F 1 Judgment: Values: e v v ::= n true false λx:τ. e The evaluation rules Audience participation time: raise your hand and give me an evaluation rule.

#30 Opsem of F 1 (Cont.) Call-by-value evaluation rules (sample) Where is the Call-By-Value? How might we change it? Evaluation is undefined for illtyped programs!

#31 Type Soundness for F 1 Thm: If ` e : τ and e v then ` v : τ Also called, subject reduction theorem, type preservation theorem This is one of the most important sorts of theorems in PL Whenever you make up a new safe language you are expected to prove this Examples: Vault, TAL, CCured, Proof: next time!

#32 Homework Read actually-exciting Leroy paper Finish Homework 5? Work on your projects! Status Update Due