COMP 412, FALL 2000 1 Type Systems II C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.

Slides:



Advertisements
Similar presentations
Types and Programming Languages Lecture 4 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Advertisements

Types and Programming Languages Lecture 13 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Types and Programming Languages Lecture 15 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Types and Programming Languages Lecture 7 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Functional Programming Lecture 10 - type checking.
Type Inference David Walker COS 320. Criticisms of Typed Languages Types overly constrain functions & data polymorphism makes typed constructs useful.
Type Checking, Inference, & Elaboration CS153: Compilers Greg Morrisett.
Cs776 (Prasad)L4Poly1 Polymorphic Type System. cs776 (Prasad)L4Poly2 Goals Allow expression of “for all types T” fun I x = x I : ’a -> ’a Allow expression.
1 Mooly Sagiv and Greta Yorsh School of Computer Science Tel-Aviv University Modern Compiler Design.
CSE 3341/655; Part 4 55 A functional program: Collection of functions A function just computes and returns a value No side-effects In fact: No program.
Getting started with ML ML is a functional programming language. ML is statically typed: The types of literals, values, expressions and functions in a.
Functional Programming. Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends.
Type checking © Marcelo d’Amorim 2010.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
INF 212 ANALYSIS OF PROG. LANGS Type Systems Instructors: Crista Lopes Copyright © Instructors.
Catriel Beeri Pls/Winter 2004/5 last 55 Two comments on let polymorphism I. What is the (time, space) complexity of type reconstruction? In practice –
Foundations of Programming Languages: Introduction to Lambda Calculus
Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Catriel Beeri Pls/Winter 2004/5 type reconstruction 1 Type Reconstruction & Parametric Polymorphism  Introduction  Unification and type reconstruction.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Type Inference David Walker COS 441. Criticisms of Typed Languages Types overly constrain functions & data polymorphism makes typed constructs useful.
Type Inference David Walker CS 510, Fall Criticisms of Typed Languages Types overly constrain functions & data polymorphism makes typed constructs.
Type Inference: CIS Seminar, 11/3/2009 Type inference: Inside the Type Checker. A presentation by: Daniel Tuck.
Local Definitions, Scope, Functional Abstraction, and Polymorphism.
Functional Programming Element of Functional Programming.
Ryan Chu. Arithmetic Expressions Arithmetic expressions consist of operators, operands, parentheses, and function calls. The purpose is to specify an.
The Relational Model: Relational Calculus
1 COMP313A Functional Programming (1). 2 Main Differences with Imperative Languages Say more about what is computed as opposed to how Pure functional.
Typed Lambda Calculus Chapter 9 Benjamin Pierce Types and Programming Languages.
Formal Semantics Chapter Twenty-ThreeModern Programming Languages, 2nd ed.1.
Type Inference II David Walker COS 441. Type Inference Goal: Given unannotated program, find its type or report it does not type check Overview: generate.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
CPS 506 Comparative Programming Languages Syntax Specification.
Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. L06-1 September 26, 2006http:// Type Inference September.
Chapter 3 Part II Describing Syntax and Semantics.
COMP313A Functional Programming (1)
CS535 Programming Languages Chapter - 10 Functional Programming With Lists.
12/9/20151 Programming Languages and Compilers (CS 421) Elsa L Gunter 2112 SC, UIUC Based in part on slides by Mattox.
Top-down Parsing Recursive Descent & LL(1) Comp 412 Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 412.
Advanced Formal Methods Lecture 3: Simply Typed Lambda calculus Mads Dam KTH/CSC Course 2D1453, Some material from B. Pierce: TAPL + some from.
Types and Programming Languages Lecture 11 Simon Gay Department of Computing Science University of Glasgow 2006/07.
A Type System for Higher-Order Modules Derek Dreyer, Karl Crary, and Robert Harper Carnegie Mellon University POPL 2003.
Comp 311 Principles of Programming Languages Lecture 4 The Scope of Variables Corky Cartwright September 3, 2008.
Semantic Analysis II Type Checking EECS 483 – Lecture 12 University of Michigan Wednesday, October 18, 2006.
Advanced Functional Programming Tim Sheard 1 Lecture 17 Advanced Functional Programming Tim Sheard Oregon Graduate Institute of Science & Technology Lecture:
Types and Programming Languages Lecture 14 Simon Gay Department of Computing Science University of Glasgow 2006/07.
CS7120 (Prasad)L13-1-Lambda-Opt1 Typed Lambda Calculus Adapted from Lectures by Profs Aiken and Necula of Univ. of California at Berkeley.
Types and Programming Languages Lecture 10 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. L04Ext-1 September 21, 2006http:// Some more thoughts.
Types and Programming Languages Lecture 3 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Prof. Necula CS 164 Lecture 171 Operational Semantics of Cool ICOM 4029 Lecture 10.
Cs776(Prasad)L6sml971 SML-97 Specifics SML/NJ 110.
1 Proving Properties of Recursive List Functions CS 270 Math Foundations of CS Jeremy Johnson.
COMP 412, FALL Type Systems C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. L05-1 September 21, 2006http:// Types and Simple Type.
Lesson 10 Type Reconstruction
CS5205: Foundation in Programming Languages Type Reconstruction
CS314 – Section 5 Recitation 9
Type Checking and Type Inference
Programming Languages and Compilers (CS 421)
ML: a quasi-functional language with strong typing
Corky Cartwright January 18, 2017
Lesson 4 Typed Arithmetic Typed Lambda Calculus
Programming Languages and Compilers (CS 421)
Introduction to Parsing
Continuation Marks A john clements talk.
UNIT V Run Time Environments.
Programming Languages and Compilers (CS 421)
Presentation transcript:

COMP 412, FALL Type Systems II C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit permission to make copies of these materials for their personal use.

COMP 412, FALL Type Systems: Simply Typed -calculus Realistic core language suitable for type-checking M ::= c | x | (M M … M) | ( x:  … x: . M) | if M then M  ::= b |  ...     b  B (a set of base types including bool, ) c  C (a set of constants including true, false), c  C has a given type  (c) x  V (a set of variables), variables in (x:  … x:  ) must be distinct Typing rules:  , x:  | x:    | c:  (c) [  (true) = bool,  (false) = bool ]   | M:  1 ...   k  ,  | N 1 :  1,…,  | N k :  k (app rule)  | (M N 1 … N k ): .  , x 1 :  1, …, x k :  k | M: . (abs rule)  | ( x 1 :  1 …x k :  k. M):  1 ...   k     | M 1 : bool,  | M 2 : ,  | M 3 :  (if rule)  | if M 1 then M 2 else M 3 : 

COMP 412, FALL Type Systems : Sample Typing Proof Show  | (( f :bool  bool. ( x:bool. (f (f x)))) ( x:bool. x)) : bool  bool Tree1: f :bool  bool, x:bool | f :bool  bool, f :bool  bool, x:bool | x :bool f :bool  bool, x:bool | (f x): bool Tree2: f :bool  bool, x:bool | f :bool  bool, Tree1 f :bool  bool, x:bool | (f (f x)): bool f :bool  bool | ( x:bool. (f (f x))): bool  bool  | (( f :bool  bool. ( x:bool. (f (f x)))) : (bool  bool)  (bool  bool) Tree3: x:bool | x:bool  | ( x:bool. x)) : bool  bool Tree4: Tree2, Tree3  | (( f :bool  bool. ( x:bool. (f (f x)))) ( x:bool. x)) : bool  bool

COMP 412, FALL Is (( f : . ( x: . (f (f x)))) ( x: . x)) typable? What is its principal type? Tree1: f : , x:  | f : , f : , x:  | x:  [  =  1   2,  =  1 ] f :  1   2, x:  1 | (f x):  2 Tree2: f :  1   2, x:  1 | f :  1   2, Tree1 [  2 =  1 ] f :  1   1, x:  1 | (f (f x)):  1 f :  1   1 | ( x:  1. (f (f x))) :  1   1  | (( f :  1   1. ( x:  1. (f (f x)))) : (  1   1)  (  1   1) Tree3: x:  | x:   | ( x: . x)) :    Tree4: Tree2, Tree3 [  =  1]  | (( f :  1   1. ( x:  1. (f (f x)))) ( x:  1. x)) :  1   1 Type Systems: Sample Type Reconstruction

COMP 412, FALL Type Systems: Formalizing Polymorphism One extension to the simply typed language: (let x := M in M) where let is recursive (scope of x includes the right hand side of definition of x) Five extensions to our simple type system:  Type variables:  1,  2,...  Type schemes:  ::=  1 …  k.  where  is a type. Type schemes are not types!  Type environments (symbol tables) can contain type schemes; so can the table .  Additional inference rules: , x:  1 …  k.  | x: OPEN(  1 …  k. ,  1, …,  k ) (instantiation) [  1, …,  k are type variables] , x:  1 | M:  1, , x:CLOSE(  1,  ) | N:  (letpoly)  | (let x := M in N):   Additional axiom:  | c: OPEN(  (c),  1, …,  k ) where c  C and  (c) =  1 …  k. 

COMP 412, FALL Type Systems: Formalizing Polymorphism continued Notes  The notation OPEN(  1 …  k. ,  1, …,  k ) means convert the type scheme  1 …  k.  to the type  ’ where  ’ is  with type variables  1 …  k replaced by “fresh” type variables  1, …,  k.  The notation CLOSE(  1,  ) means convert the type  1 to the type scheme  1 …  k.  1 where  1, …,  k are the type variables that appear in  1 but not . Intuition:  Polymorphism abbreviates brute force replication of the definition introduced in a let. The new type variables that appear in the type of M (rhs of the let binding) are arbitrary. The instantiation and polylet rules lets us adapt a symbolic type for M to each of the specific uses of x (the lhs of the let binding) in N (the body of the let).  The rhs side of the let binding cannot use x polymorphically because such usage is inconsistent with the fact that polymorphic let is an abbreviation mechanism!

COMP 412, FALL Type Systems: Sample Polymorphic Type Reconstruction Consider a functional language with polymorphic lists. The operations on polymorphic lists include the binary function cons, unary functions first and rest, and the constant null. A sample program in this language is: (let length := ( x (if (null? x) then 0 else (+ 1 (length (rest x))))) in (+ (length (cons 1 null)) (length (cons true null)))) Can we type it? Sketch:  | length:  list  int Use letpoly rule to add length to type environment with polymorphic type. Instantiate it twice: once for bool and once for int.

COMP 412, FALL Type Systems: Sample Polymorphic Type Reconstruction Claim:  | (let length := ( x. (if (null? x) then 0 else (+ 1 (length (rest x))))) in (+ (length (cons 1 null)) (length (cons true null)))):int Tree1: length: , x:  1 | null?:  -list  bool, length: , x:  1 | x:  1 [  1 =  -list] length: , x:  -list | (null? x):bool Tree2: length: , x:  -list | rest:  2 -list  2 -list, length: , x:  -list | x:  -list [  2 =  ] length: , x:  -list | (rest x):  -list length:  -list  2, x:  -list | (length (rest x)):  2 [  =  -list  2] length:  -list  int, x:  -list | (+ 1 length(rest x)):int [  2 = int] Tree3: Tree1, length:  -list  int, x:  -list | 0:int, Tree2 length:  -list  int, x:  -list | if (null? x) then 0 else (+ 1 (length (rest x))))) in (+ (length (cons 1 null)) (length (cons true null)))):int length:  -list  int | x. if (null? x) then 0 else (+ 1 (length (rest x))))) in (+ (length (cons 1 null)) (length (cons true null)))):  -list  int Tree4: length:  .  -list  int | cons:  3  3 -list  3 -list, length:  .  -list  int | 1:int, length:  .  -list  int | null:  4 -list [  3 =  4 = int ] length:  .  -list  int | (cons 1 null):int-list Tree5: length:  .  -list  int | length:  5 -list  int, Tree4 [  5 =int] length:  .  -list  int | (length (cons 1 null)): int Tree6: length:  .  -list  int | cons:  6  6 -list  6 -list, length:  .  -list  int | true:bool, length:  .  -list  int | null:  7 - list length:  .  -list  int | (cons true null):bool -list length:  .  -list  int | (length (cons true null)):int

COMP 412, FALL Type Systems: Sample Polymorphic Type Reconstruction, cont. Tree7: Tree5, Tree6, length:  .  -list  int | +: int  int  int length:  .  -list  int | (+ (length (cons 1 null)) (length (cons true null))): int Tree8: Tree3, Tree7  | (let length := ( x. (if (null? x) then 0 else (+ 1 (length (rest x))))) in (+ (length (cons 1 null)) (length (cons true null)))):int

COMP 412, FALL Type Systems: Coping with Imperativity  If replicating the let definition x := M (renaming the defined variable x) for each use of x in M does not preserve the meaning of programs, then programs written using Milner style polymorphism may not be type correct. In an imperative language, this phenomenon can happen in several ways. First, the evaluation of M may have side effects. Second, the value of x may allocate mutable storage which is shared when x := M is a single definition but split (among the various type instantions) when the definition is replicated. In an imperative language this splitting can be detected by mutating allocated storage.  To avoid this problem, we can restrict M to a form that guarantees replication does not change the meaning of programs. This restricted form prevents M from performing side-effects and from allocating shared mutable storage.  If we restrict M to a syntactic value (a constant, variable, or -expression) then no side effect or sharing of mutable storage can occur. The most modern languages that use Hindley-Milner polymorphism use this restriction. Standard ML uses a much more complicated and less useful restriction (that is incomparable to the syntactic value test).

COMP 412, FALL Type Systems: Coping with Imperativity  We can incorporate the value restriction in our type system by refining the definition of CLOSE so that it does not generalize the free type variables when then rhs of a definition is not a syntactic value.  Let us extend our polymorphic -calculus language to imperative form in the same way that we did for Jam by adding the type constant unit, the unary type constructor ref, the unary operations ref: *  ref * and !: ref *  *, and the binary operation  : ref *  *  unit.  The following polymorphic imperative program generates a run-time type error even though it can be statically typed checked using our rules omitting the value restriction. let x := ref null in { (  x cons(true,null); (+ (! x) 1) } In the absence of the value restriction, this program is typable, because x has polymorphic type ref *, enabling each occurrence of x in the let body to be separately typed. Hence the first occurrence of x has type ref bool while the second has type ref int.  The value restriction prevents polymorphic generalization in this case, preserving type soundness.