Lesson 5 Simple extensions of the typed lambda calculus

Slides:



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

A Third Look At ML 1. Outline More pattern matching Function values and anonymous functions Higher-order functions and currying Predefined higher-order.
Type Checking, Inference, & Elaboration CS153: Compilers Greg Morrisett.
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists Dan Grossman Winter 2013.
ML Lists.1 Standard ML Lists. ML Lists.2 Lists  A list is a finite sequence of elements. [3,5,9] ["a", "list" ] []  ML lists are immutable.  Elements.
ML Datatypes.1 Standard ML Data types. ML Datatypes.2 Concrete Datatypes  The datatype declaration creates new types  These are concrete data types,
1 Programming Languages (CS 550) Lecture Summary Functional Programming and Operational Semantics for Scheme Jeremy R. Johnson.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Winter 2013.
Getting started with ML ML is a functional programming language. ML is statically typed: The types of literals, values, expressions and functions in a.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Chapter ElevenModern Programming Languages1 A Fourth Look At ML.
CSE341: Programming Languages Lecture 5 Pattern-Matching Dan Grossman Fall 2011.
0 PROGRAMMING IN HASKELL Chapter 4 - Defining Functions.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Functional programming: LISP Originally developed for symbolic computing Main motivation: include recursion (see McCarthy biographical excerpt on web site).
Introduction to ML - Part 2 Kenny Zhu. What is next? ML has a rich set of structured values Tuples: (17, true, “stuff”) Records: {name = “george”, age.
Introduction to ML Last time: Basics: integers, Booleans, tuples,... simple functions introduction to data types This time, we continue writing an evaluator.
Functional programming: LISP Originally developed for symbolic computing First interactive, interpreted language Dynamic typing: values have types, variables.
SchemeCOP Introduction to Scheme. SchemeCOP Scheme Meta-language for coding interpreters –“ clean ” semantics Scheme = LISP + ALGOL –simple.
CS 2104 : Prog. Lang. Concepts. Functional Programming I Lecturer : Dr. Abhik Roychoudhury School of Computing From Dr. Khoo Siau Cheng’s lecture notes.
Lesson 4 Typed Arithmetic Typed Lambda Calculus 1/21/02 Chapters 8, 9, 10.
Chapter 9: Functional Programming in a Typed Language.
Lee CSCE 314 TAMU 1 CSCE 314 Programming Languages Haskell: Types and Classes Dr. Hyunyoung Lee.
Functional Programming With examples in F#. Pure Functional Programming Functional programming involves evaluating expressions rather than executing commands.
F28PL1 Programming Languages Lecture 13: Standard ML 3.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
A Third Look At ML Chapter NineModern Programming Languages, 2nd ed.1.
Homogeneous tuples What are they? –S 2 = S x S –S n = S x S x … x S Cardinalities –#(S 2 )= (#S) 2 –#(S n )= (#S) n –#(S 0 )= (#S) 0 =1 What is S 0 ? –It.
1 CS 457/557: Functional Languages Lists and Algebraic Datatypes Mark P Jones Portland State University.
Advanced Formal Methods Lecture 4: Isabelle – Types and Terms Mads Dam KTH/CSC Course 2D1453, Some material from Paulson.
CSED101 INTRODUCTION TO COMPUTING SUM TYPE 유환조 Hwanjo Yu.
7/7/20161 Programming Languages and Compilers (CS 421) Dennis Griffith 0207 SC, UIUC Based in part on slides by Mattox.
1 Interactive Computer Theorem Proving CS294-9 September 7, 2006 Adam Chlipala UC Berkeley Lecture 3: Data structures and Induction.
Lecture 9 : Universal Types
Lesson 10 Type Reconstruction
Operational Semantics of Scheme
Functional Programming
CSE341: Programming Languages Lecture 21 Dynamic Dispatch Precisely, and Manually in Racket Dan Grossman Spring 2016.
Programming Languages and Compilers (CS 421)
Conditional Expressions
Principles of programming languages 12: Functional programming
Types CSCE 314 Spring 2016.
ML: a quasi-functional language with strong typing
CSE341: Programming Languages Lecture 21 Dynamic Dispatch Precisely, and Manually in Racket Dan Grossman Spring 2017.
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
A lightening tour in 45 minutes
September 4, 1997 Programming Languages (CS 550) Lecture 6 Summary Operational Semantics of Scheme using Substitution Jeremy R. Johnson TexPoint fonts.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2013.
Lesson 4 Typed Arithmetic Typed Lambda Calculus
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Zach Tatlock Winter 2018.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2017.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Autumn 2018.
Typed Arithmetic Expressions
Objective caml Daniel Jackson MIT Lab for Computer Science 6898: Advanced Topics in Software Design March 18, 2002.
FP Foundations, Scheme In Text: Chapter 14.
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Autumn 2017.
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
PROGRAMMING IN HASKELL
Types and Classes in Haskell
Streams, Delayed Evaluation and a Normal Order Interpreter
Announcements Exam 2 on Friday, November 2nd Topics
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2016.
6.001 SICP Interpretation Parts of an interpreter
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
Review Previously User-defined data types: records, variants
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2019.
Presentation transcript:

Lesson 5 Simple extensions of the typed lambda calculus Lesson 5: Extensions Lesson 5 Simple extensions of the typed lambda calculus 1/24-2/02 Chapter 11 1/31/02 Lesson 5

A toolkit of useful constructs Base types Unit Sequencing and wild cards Type ascription Let bindings Pairs, tuples and records Sums, variants, and datatypes General recursion (fix, letrec) 1/31/02 Lesson 5

Base Types Base types are primitive or atomic types. E.g. Bool, Nat, String, Float, ... Normally they have associated intro and elimination rules, or alternatively sets of predefined constants and functions for creating and manipulating elements of the type. These rules or sets of constants provide an interpretation of the type. Uninterpreted types can be used in expressions like x: A. x but no values of these types can be created. 1/31/02 Lesson 5

Type Unit Type: The type Unit has just one value: unit. Unit Terms: unit Rules:  |- unit : Unit The type Unit has just one value: unit. It is typically used as the return type of a function that is used for effect (e.g. assignment to a variable). In ML, unit is written as “( )”. It plays a role similar to void in C, Java. 1/31/02 Lesson 5

Derived forms Sequencing: t1; t2 Can be treated as a basic term form, with its own evaluation and typing rules (call this E, the external language): t1  t1’ (E-Seq) unit; t2  t2 (E-SeqNext) t1; t2  t1’; t2  |- t1 : Unit  |- t2 : T2 (T-Seq)  |- t1; t2 : T2 1/31/02 Lesson 5

Sequencing as Derived Form Sequencing Can be also be treated as an abbreviation: t1; t2 =def (x: Unit. t2) t1 (with x fresh) This definition can be used to map E to the internal language I consisting of  with Unit. Elaboration function e: E  I e(t1; t2) = (x: Unit. t2) t1 e(t) = t otherwise 1/31/02 Lesson 5

Elaboration theorem Theorem: For each term t of E we have t E t’ iff e(t) I e(t’)  |-E t : T iff  |-I e(t) : T Proof: induction on the structure of t. 1/31/02 Lesson 5

Type ascription Terms: t as T Eval Rules: v as T  v (E-Ascribe) t1  t1’ (E-Ascribe1) t1 as T  t1’ as T Type Rules:  |- t1 : T (T-Ascribe)  |- t1 as T : T 1/31/02 Lesson 5

Let expressions Terms: let x = t1 in t2 Eval Rules: let x = v in t  [x  v]t (E-LetV) t1  t1’ (E-Let) let x = t1 in t2  let x = t1’ in t2 Type Rules:  |- t1 : T1 , x: T1 |- t2 : T2 (T-App)  |- let x = t1 in t2 : T2 1/31/02 Lesson 5

Let expressions Let as a derived form e(let x = t1 in t2) = (x : T. t2) t1 but where does T come from? Could add type to let-binding: let x: T = t1 in t2 or could use type checking to discover it. 1/31/02 Lesson 5

Pairs Types: T1 T2 Terms: {t, t} | t.1 | t.2 Values: {v, v} Eval Rules: (i = 1,2) t1  t1’ {v1,v2}.i  v1 (E-PairBeta i) (E-Proj i) t1.i  t1’.i t1  t1’ (E-Pair1) {t1, t2}  {t1’, t2} t2  t2’ (E-Pair2) {v1, t2}  {v1, t2’} 1/31/02 Lesson 5

Pairs - Typing Typing Rules:  |- t1 : T1  |- t2 : T2 (T-Pair) (T-Proj i)  |- t.i : Ti Naive semantics: Cartesian product T1  T2 = {(x,y) | x  T1 and y  T2} 1/31/02 Lesson 5

Properties of Pairs 1. access is positional -- order matters (3, true)  (true, 3) Nat  Bool  Bool  Nat 2. evaluation is left to right (print “x”, raise Fail) prints and then fails (raise Fail, print “x”) fails and does not print 3. projection is “strict” -- pair must be fully evaluated 1/31/02 Lesson 5

Tuples Type constructors: {T1, T2, ..., Tn} or T1 T2  ... Tn Tuple terms {t1, t2, ..., tn} or (t1, t2, ..., tn) Projections t : {T1, T2, ..., Tn} => t.i : Ti (i = 1, ..., n) 1/31/02 Lesson 5

Properties of Tuples Evaluation and typing rules are the natural generalizations of those for tuples. Evaluation is left-to-right. Tuples are fully evaluated before projection is evaluated. Pairs are a special case of tuples. Examples: {true, 1, 3} : {Bool, Nat, Nat} (or Bool  Nat  Nat) {true, 1} : {Bool, Nat} (equivalent to Bool  Nat) 1/31/02 Lesson 5

Records Records are “labelled tuples”. {name = “John”, age = 23, student = true} : {name: String, age: Nat, student: Bool} Selection/projection is by label, not by position. let x = {name = “John”, age = 23, student = true} in if x.student then print x.name else unit t : {name: String, age: Nat, student: Bool} => t.name : String, t.age : Nat, t.student : Bool Components of a record are called fields. 1/31/02 Lesson 5

Records - Evaluation Evaluation of record terms is left to right, as for tuples. Tuples are fully evaluated before projection is evaluated. Order of fields matters for evaluation let x = ref 0 in {a = !x, b = (x := 1; 2)} * {a = 0, b = 2} in {b = (x := 1; 2), a = !x} * {b = 2, a = 1} 1/31/02 Lesson 5

Records - Field order Different record types can have the same labels: {name: String, age: Nat}  {age: Nat, name: Bool} What about order of fields? Are these types equal? {name: String, age: Nat} = {age: Nat, name: String} ? We can choose either convention. In SML, field order is not relevant, and these two types are equal. In other languages, and in the text (for now), field order is important. and these two types are different. 1/31/02 Lesson 5

Extending Let with Patterns let {name = n, age = a} = find(key) in if a > 21 then name else “anonymous” The left hand side of a binding in a let expression can be a record pattern, that is matched with the value of the rhs of the binding. We can also have tuple patterns: let (x,y) = coords(point) in ... x ... y ... See Exercise 11.8.2 and Figure 11-8. 1/31/02 Lesson 5

Sum types Types: T1 + T2 Terms: inl t inr t case t of inl x => t | inr x => t Values: inl v inr v 1/31/02 Lesson 5

Sum types Sum types represent disjoint, or discriminated unions Bool isl Bool inl A isr inl B outl inr inl outr A B 1/31/02 Lesson 5

Sum types A + B = {(1,a) | a  A}  {(2,b) | b  B} inl a = (1,a) inr b = (2,b) outl (1,a) = a outr(2,b) = b isl (1,a) = true; isl (2,b) = false isr (1,a) = false; isr (2,b) = true case z of inl x => t1 | inr y => t2 = if isl z then (x. t1)(outl z) else (y. t2)(outr z) 1/31/02 Lesson 5

Sums - Typing  |- t1 : T1  |- t2 : T2 (T-Inl) (T-Inr)  |- inl t1 : T1 +T2  |- inr t2 : T1 +T2  |- t : T1 +T2 , x1: T1 |- t1 : T , x2: T2 |- t2 : T  |- case t of inl x1 => t1 | inr x2=> t2 : T (T-Case) 1/31/02 Lesson 5

Typing Sums Note that terms do not have unique types: inl 5 : Nat + Nat and inl 5 : Nat + Bool Can fix this by requiring type ascriptions with inl, inr:  |- t1 : T1 (T-Inl)  |- inl t1 as T1 +T2 : T1 +T2  |- t2 : T2 (T-Inr)  |- inr t2 as T1 +T2 : T1 +T2 1/31/02 Lesson 5

Labeled variants Could generalize binary sum to n-ary sums, as we did going from pairs to tuples. Instead, go directly to labeled sums: type NatString = <nat: Nat, string: String> a = <nat = 5> as NatString b = <string = “abc”> as NatString x: NatString . case x of <nat = x> => numberOfDigits x | <string = y> => stringLength y 1/31/02 Lesson 5

Option An option type is a useful special case of labeled variants. type NatOption = <some: Nat, none: Unit> someNat = x: Nat . <some = x> as NatOption : Nat -> NatOption noneNat = <none = unit> as NatOption : NatOption half = x: Nat . if equal(x, 2 * (x div 2)) then someNat(x div 2) else noneNat : Nat -> NatOption 1/31/02 Lesson 5

Enumerations Enumerations are anonther common form of labeled variants. They are a labeled sum of several copies of Unit. type WeekDay = <monday: Unit, tuesday: Unit, wednesday: Unit, thursday: Unit, friday: Unit> monday = <monday = unit> as WeekDay type Bool = <true: Unit, false: Unit> true = <true = unit> as Bool false = <false = unit> as Bool 1/31/02 Lesson 5

ML Datatypes ML datatypes are a restricted form of labeled variant type + recursion + parameterization datatype NatString = Nat of Nat | String of String fun size x = case x of Nat n => numberOfDigits n | String s => stringLength s datatype NatOption = Some of Nat | None datatype ‘a Option = Some of ‘a | None (‘a is a type variable) datatype Bool = True | False datatype ‘a List = Nil | Cons of ‘a * ‘a List (recursive type defn) 1/31/02 Lesson 5

General Recursion The fixed point combinator (p. 65), can’t be defined in . So we need to defined a special fix operator. Terms: fix t Evaluation fix(x: T. t)  [x  (fix(x: T. t))]t (E-FixBeta) t1  t1’ (E-Fix) fix t1  fix t1’ 1/31/02 Lesson 5

General Recursion - Typing  |- t1 : T1 -> T1 (T-Fix)  |- fix t1 : T1 The argument t1 of fix is called a generator. Derived form: letrec x: T1 = t1 in t2 =def let x = fix(x: T1. t1) in t2 1/31/02 Lesson 5

Mutual recursion The generator is a term of type T->T for some T, which is typically a function type, but may be a tuple or record of function types to define a family of mutually recursive functions. ff = ieio: {iseven: Nat -> Bool, isodd: Nat -> Bool} . {iseven = x: Nat . if iszero x then true else ieio.isodd (pred x), isodd = x: Nat . if iszero x then false else ieio.iseven (pred x)} : T -> T where T is {iseven: Nat -> Bool, isodd: Nat -> Bool} r = fix ff : {iseven: Nat -> Bool, isodd: Nat -> Bool} iseven = r.iseven : Nat -> Bool 1/31/02 Lesson 5

Lists Type: List T Terms: nil[T] cons[T] t t isnil[T] t head[T] t tail[T] t Values: nil[T] cons[T] v v 1/31/02 Lesson 5

Lists - Evaluation Eval rules: isnil[S](nil[T])  true (E-IsnilNil) head[S](cons[T] v1 v2)  v1 (E-HeadCons) tail[S](cons[T] v1 v2)  v2 (E-TailCons) plus usual congruence rules for evaluating arguments. 1/31/02 Lesson 5

Lists - Typing  |- nil[T1] : List T1 (T-Nil)  |- t1 : T1 (T-Cons)  |- cons[T1] t1 t2 : List T1  |- t : List T1 (T-Isnil)  |- isnil[T1] t : Bool  |- t : List T1  |- t : List T1 (T-Head) (T-Tail)  |- head[T1] t : T1  |- head[T1] t : List T1 1/31/02 Lesson 5