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

Similar documents
Simply-Typed Lambda Calculus

More Lambda Calculus and Intro to Type Systems

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

Programming Languages Fall 2014

More Lambda Calculus and Intro to Type Systems

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

More Lambda Calculus and Intro to Type Systems

Formal Systems and their Applications

Programming Languages

CIS 500 Software Foundations Fall October 2

(Advanced) topics in Programming Languages

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

Concepts of programming languages

Typed Lambda Calculus. Chapter 9 Benjamin Pierce Types and Programming Languages

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

CS558 Programming Languages

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

Programming Languages Third Edition

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.

Axiomatic Rules. Lecture 18: Axiomatic Semantics & Type Safety. Correctness using Axioms & Rules. Axiomatic Rules. Steps in Proof

COS 320. Compiling Techniques

Simply-Typed Lambda Calculus

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.

Lecture 5: The Untyped λ-calculus

Formal Semantics. Aspects to formalize. Lambda calculus. Approach

λ calculus Function application Untyped λ-calculus - Basic Idea Terms, Variables, Syntax β reduction Advanced Formal Methods

Lesson 4 Typed Arithmetic Typed Lambda Calculus

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

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

Chapter 3. Describing Syntax and Semantics

CS152 Programming Language Paradigms Prof. Tom Austin, Fall Syntax & Semantics, and Language Design Criteria

Chapter 3 (part 3) Describing Syntax and Semantics

CS558 Programming Languages

Chapter 3. Describing Syntax and Semantics ISBN

Costly software bugs that could have been averted with type checking

Chapter 3. Describing Syntax and Semantics ISBN

What Is Computer Science? The Scientific Study of Computation. Expressing or Describing

4.5 Pure Linear Functional Programming

The University of Nottingham SCHOOL OF COMPUTER SCIENCE A LEVEL 4 MODULE, SPRING SEMESTER MATHEMATICAL FOUNDATIONS OF PROGRAMMING ANSWERS

Lambda Calculus. Type Systems, Lectures 3. Jevgeni Kabanov Tartu,

Formal Semantics of Programming Languages

The Compiler So Far. CSC 4181 Compiler Construction. Semantic Analysis. Beyond Syntax. Goals of a Semantic Analyzer.

Last class. CS Principles of Programming Languages. Introduction. Outline

Formal Semantics of Programming Languages

Chapter 3. Describing Syntax and Semantics

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor

INF 212/CS 253 Type Systems. Instructors: Harry Xu Crista Lopes

CIS 500 Software Foundations Midterm I Answer key October 8, 2003

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

7. Introduction to Denotational Semantics. Oscar Nierstrasz

Type Systems. Luca Cardelli. Digital Equipment Corporation Systems Research Center

Boolean expressions. Elements of Programming Languages. Conditionals. What use is this?

Chapter 3: Describing Syntax and Semantics. Introduction Formal methods of describing syntax (BNF)

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

Type Systems Winter Semester 2006

Programmiersprachen (Programming Languages)

Variables. Substitution

CIS 500 Software Foundations Midterm I

More Untyped Lambda Calculus & Simply Typed Lambda Calculus

Types and Programming Languages. Lecture 5. Extensions of simple types

INF 212 ANALYSIS OF PROG. LANGS Type Systems. Instructors: Crista Lopes Copyright Instructors.

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

Lambda Calculi With Polymorphism

CS383 PROGRAMMING LANGUAGES. Kenny Q. Zhu Dept. of Computer Science Shanghai Jiao Tong University

CIS 500 Software Foundations Fall September 25

Com S 541. Programming Languages I

The lambda calculus (An introduction)

Contents. Chapter 1 SPECIFYING SYNTAX 1

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

The Untyped Lambda Calculus

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

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. Operational Semantics

CS152: Programming Languages. Lecture 2 Syntax. Dan Grossman Spring 2011

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

CPS Conversion. Di Zhao.

St. MARTIN S ENGINEERING COLLEGE Dhulapally, Secunderabad

The Lambda Calculus. 27 September. Fall Software Foundations CIS 500. The lambda-calculus. Announcements

Principles of Programming Languages

Static Semantics. Winter /3/ Hal Perkins & UW CSE I-1

COMP 181. Agenda. Midterm topics. Today: type checking. Purpose of types. Type errors. Type checking

Semantic Analysis. How to Ensure Type-Safety. What Are Types? Static vs. Dynamic Typing. Type Checking. Last time: CS412/CS413

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

G Programming Languages - Fall 2012

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

The Untyped Lambda Calculus

Lecture 13: Subtyping

10/30/18. Dynamic Semantics DYNAMIC SEMANTICS. Operational Semantics. An Example. Operational Semantics Definition Process

Modules, Structs, Hashes, and Operational Semantics

The design of a programming language for provably correct programs: success and failure

CS 6110 S14 Lecture 1 Introduction 24 January 2014

CSCI312 Principles of Programming Languages!

An Annotated Language

Types and Programming Languages. Lecture 6. Normalization, references, and exceptions

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

Lambda Calculus. Concepts in Programming Languages Recitation 6:

CS558 Programming Languages

Type Systems Winter Semester 2006

Transcription:

Today Type Systems 1. Organizational Matters 2. What is this course about? 3. Where do types come from? 4. Def. of the small language Expr. Its syntax and semantics. Lecture 1 Oct. 20th, 2004 Sebastian Maneth 5. Structural Induction on Expr s http://lampwww.epfl.ch/teaching/typesystems/2004 1. Organizational Matters 1. Organizational Matters Lectures: We 13:15-15:00, INM203 Sebastian Maneth BC360, 021-69 31226 (last 3 lectures by Martin Odersky) Exercises (lab): We 15:15-17:00, INR 331 Burak Emir INR320, 021-69 36867 Course Book: Benjamin Pierce, Types and Programming Languages MIT Press, 2002. We will strictly follow this book! So: Good to buy it! To get credits you have to: 1/3 2/3 1-2 written assignments one programming assignment oral examination

Type Systems for Programming Languages Type Systems for Programming Languages exe What for?? to prevent execution errors. Definition of prog.lang. P A compiler for P A PL in which all well-typed programs are free of execution errors is called type sound. Definition of type system T is (P, T) type sound? is T decidable? does C correctly implement T? A typechecker C for T program What you will learn in this course: how to define a type system T (to allow for unambiguous implementations) Type Systems in Programming Languages What for?? to prevent execution errors. how to formally prove that (P, T) is type sound how to implement a typechecker for T

Execution Errors Execution Errors trapped computation stops immediately examples: division by zero accessing an illegal addr. trapped computation stops immediately examples: division by zero accessing an illegal addr. untrapped later causes arbitrary behavior jump to a wrong addr. accessing past the end of an array untrapped later causes arbitrary behavior jump to a wrong addr. accessing past the end of an array A program is SAFE if it does not have untrapped errors. A PL is SAFE if all its programs are safe. A program is SAFE if it does not have untrapped errors. A PL is SAFE if all its programs are. trapped + some forbidden untrapped errors := well-behaved What is a TYPE, in our context? A type is an upper bound of the range of values that a program variable can assume during execution. e.g. if x has type Boolean, then in all runs it should only take one of the values true / false. not(x) has a meaning in every run PLs in which variables can be given nontrivial types are called TYPED languages. safe/unsafe and typed/untyped typed untyped safe ML, Java LISP unsafe C Assembler safety integrity of run-time structures enables garbage collection saves code size / develop. time (price: performance)

safe/unsafe and typed/untyped typed untyped safe ML, Java LISP unsafe C Assembler safety integrity of run-time structures enables garbage collection var x : Boolean x := 10; typechecker should complain! caveat: of course no one knows if this line will ever be executed! but it just not SAFE to have it. should not be allowed to write such a program: it has no meaning! SECURITY vs. PERFORMANCE saves code size / develop. time (price: performance) TYPE SYSTEMS are there to PROTECT YOU from making stupid (obvious) mistakes. Type Theory is much older than PLs! Bertrand Russell (1872-1970) 1901 Russell s Paradox Let P = { Q sets Q Q} then: P P P P Naive set theory is inconsistent! MUST eliminate self-referential defs. to make set theory consistent HOW? 1903 define a hierarchy of types: individuals, sets, sets of set, etc. Any well defined set can only have elements from lower levels. Course Outline today: Intro, Arithm. Expressions, Induction, Evaluation LAB1 next: (untyped) Lambda-Calculus LAB2 untyped λ-evaluator 3 rd : Simply-Typed Lambda-Calculus LAB3 simply typed w. let/fix 4 rd : Simple Extensions, Subtyping LAB4 subtyping on records 5 th : Subtyping, Featherweight Java LAB5 6 th : Recursive Types I 7 th : Recursive Types II 8 th : Polymorphism I 9 th : Polymorphism II 10 th : Bounded Quantification 11-13 th : Scala s Type System (by Martin Odersky)

1960 Irons, Syntax-Directed Compiler for ALGOL 60 1960 Irons, Syntax-Directed Compiler for ALGOL 60 Compiler Compiler Defining Translating 1960 Irons, Syntax-Directed Compiler for ALGOL 60 Compiler Defining Translating 1966 Younger, O(n^3) Parsing of Context-Free Grammars Until today, EBNF (ext. cf. grammar) is used to describe the syntax of a programming language. Example: Arithmetic Expressions Expr ::= true false zero Expr ::= if Expr then Expr else Expr Expr ::= succ Expr Expr ::= pred Expr Expr ::= iszero Expr Syntax Check Parse Tree Translator Derivable Expressions: pred succ zero if iszero pred succ zero then zero else true if zero then true else false

Until today, EBNF (ext. cf. grammar) is used to describe the syntax of a programming language. Example: Arithmetic Expressions Derivable Expressions: Expr ::= true false zero Expr ::= if Expr then Expr else Expr Expr ::= succ (Expr) Expr ::= pred (Expr) Expr ::= iszero (Expr) Until today, EBNF (ext. cf. grammar) is used to describe the syntax of a programming language. Example: Arithmetic Expressions Derivable Expressions: Expr ::= true false zero Expr ::= if Expr then Expr else Expr Expr ::= succ (Expr) Expr ::= pred (Expr) Expr ::= iszero (Expr) pred (succ (zero)) if iszero (pred (succ (zero))) then zero else true if zero then true else false pred (succ (zero)) if iszero (pred (succ (zero))) then zero else true if zero then true else false semantics?? Alternative Formalism: Inference Rules The set of expressions is the smallest set E such that: true E false E zero E t 1 E succ t 1 E t 1 E pred t 1 E t 1 E t 2 E t 3 E if t 1 then t 2 else t 3 E t 1 E iszero t 1 E 1. Operational Semantics: behavior defined in terms of abstract machines 2. Denotational Semantics: maps programs by an interpretation function into a collection of semantic domains (such as, e.g., numbers, functions, etc.) 3. Axiomatic Semantics: proves properties of a program by applying laws about program behavior (e.g., given that properties P hold before a statement, what properties Q hold after executing it?)

1. Operational Semantics: behavior defined in terms of abstract machines 2. Denotational Semantics: maps programs by an interpretation function into a collection of semantic domains (such as, e.b., numbers, functions, etc) 3. Axiomatic Semantics: proves properties of a program by applying laws about program behavior (e.g., given that properties P hold before a statement, what properties Q hold after executing it?) Expr ::= true false zero Expr ::= if Expr then Expr else Expr Expr ::= succ (Expr) Expr ::= pred (Expr) Expr ::= iszero (Expr) Val ::= true false NVal NVal ::= zero succ NVal Evaluation Relation on Expr s if true then t 2 else t 3 t 2 if false then t 2 else t 3 t 3 if t 1 then t 2 else t 3 Expr ::= true false zero Expr ::= if Expr then Expr else Expr Expr ::= succ (Expr) Expr ::= pred (Expr) Expr ::= iszero (Expr) Val ::= true false NVal NVal ::= zero succ NVal Evaluation Relation on Expr s if true then t 2 else t 3 t 2 if false then t 2 else t 3 t 3 if t 1 then t 2 else t 3 if t 1 then t 2 else t 3 E

if iszero pred succ zero then zero else succ zero if t 1 then t 2 else t 3 E if t 1 then t 2 else t 3 E if iszero pred succ zero then zero else succ zero if iszero pred succ zero then zero else succ zero if iszero zero then zero else succ zero if t 1 then t 2 else t 3 E if t 1 then t 2 else t 3 E

Example: if iszero pred succ pred zero then zero else succ zero if iszero pred succ zero then zero else succ zero if iszero zero then zero else succ zero Example: if iszero pred succ pred zero then zero else succ zero if iszero pred succ zero then zero else succ zero if iszero zero then zero else succ zero if t 1 then t 2 else t 3 E if true then zero else succ zero if iszero pred succ zero then zero else succ zero if iszero zero then zero else succ zero if true then zero else succ zero if iszero pred succ zero then zero else succ zero if iszero zero then zero else succ zero if true then zero else succ zero zero if true then t 2 else t 3 t 2 if true then t 2 else t 3 t 2

Induction on the Structure of Expr s The set of expressions is the smallest set E such that: is deterministic: if t t and t t then t = t 1. true, false, zero E 2. if t 1, t 2, t 3 E, then succ t 1, pred t 1, iszero t 1 E and if t 1 then t 2 else t 3 E inductive definition 2. if t = succ t 1 then we can define / proof things about Expr s by induction! Example: for any Expr t define its size as 1. if t = true false zero then size(t) = 0 2. if t = succ t pred t 1 1 iszero t 1 then size(t) = size(t 1 ) + 1 if t = if t 1 then t 2 else t 3 then size(t) = size(t 1 ) + size(t 2 ) + size(t 3 ) + 1 only rule for succ(.. ) is deterministic: if t t and t t then t = t is deterministic: if t t and t t then t = t 2. if t = succ t 1 then t = succ t 1 and t = succ t 1 for t 1, t 1 with and 2. if t = succ t 1 then t = succ t 1 and t = succ t 1 for t 1, t 1 with and by induction t 1 = t 1

is deterministic: if t t and t t then t = t is deterministic: if t t and t t then t = t 2. if t = succ t 1 then t = succ t 1 and t = succ t 1 for t 1, t 1 with and 2. if t = pred t 1 then if t 1 = succ t 11 then t = t = t 11 Thus, also t = t. by induction t 1 = t 1 because is only rule applicable. is deterministic: if t t and t t then t = t is deterministic: if t t and t t then t = t 2. if t = pred t 1 then if t 1 = succ t 11 then t = t = t 11 2. if t = pred t 1 then if t 1 = succ t 11 then t = t = t 11 because is only rule applicable. because is only rule applicable. otherwise t = pred t 1 and t = pred t 1 with and otherwise t = pred t 1 and t = pred t 1 with and Thus, also t = t. by induction t 1 = t 1

is deterministic: if t t and t t then t = t is deterministic: if t t and t t then t = t 2. if t = if t 1 then t 2 else t 3 then if t 1 = true then t = t = t 2 if t 1 = false then t = t = t 3 2. if t = if t 1 then t 2 else t 3 then if t 1 = true then t = t = t 2 if t 1 = false then t = t = t 3 otherwise t = if t 1 then t 2 else t 3 and t = if t 1 then t 2 else t 3 with and by induction t 1 = t 1 Thus, also t = t. Questions: 1. Is still deterministic if we add the new rule succ pred nv 1 nv 1 Which rule must be removed now, to keep a sane semantics? 2. What if es can be chosen freely? Is still determin.? (i.e., rules can be applied to arbitrary sub-expr s) Is confluent? Is it terminating? if t t 1 then there is a t such that t t 2 t 1 t 2 Summary we have defined the syntax of the small language called Expr. we have given a semantics to Expr s by means of an evaluation relation. we have proved by induction that for every Expr there is at most one other Expr that can be derived by the evaluation relation. Next Lecture How to define a small language for defining functions? function definition and application: the lambda-calculus