lambda calculi with polymorphism · polymorphism •kinds of polymorphism parametric polymorphism...

of 49 /49
x = 1 let x = 1 in ... x(1). !x(1) x.set(1) Lambda Calculi With Polymorphism Ralf Lämmel Programming Paradigms and Formal Semantics Resources: The slides of this lecture were derived from [Järvi], with permission of the original author, by copy & paste or by selection, annotation, or rewording. [Järvi] is in turn based on [Pierce] as the underlying textbook. [Järvi] Slides by J. Järvi: “Programming Languages ”, CPSC 604 @ TAMU (2009) [Pierce] B.C. Pierce: Types and Programming Languages, MIT Press, 2002 >1h

Author: others

Post on 24-Aug-2020

9 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

  • x = 1 let x = 1 in ...

    x(1).

    !x(1) x.set(1)

    Lambda Calculi With Polymorphism

    Ralf Lämmel

    Programming Paradigms and Formal Semantics

    Resources: The slides of this lecture were derived from [Järvi], with permission of the original author, by copy & paste or by selection, annotation, or rewording. [Järvi] is in turn based on [Pierce] as the underlying textbook.

    [Järvi] Slides by J. Järvi: “Programming Languages”, CPSC 604 @ TAMU (2009)[Pierce] B.C. Pierce: Types and Programming Languages, MIT Press, 2002

    >1h

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Polymorphism -- Why?

    • What’s the identity function?

    • In the simple typed lambda calculus, this depends on the type!

    • Examples

    ✦ λx:bool. x✦ λx:nat. x✦ λx:bool→bool. x✦ λx:bool→nat. x✦ ...

    194

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Polymorphism

    • Polymorphic function✦ a function that accepts many types of arguments.

    • Kinds of polymorphism✦ Parametric polymorphism (“all types”)✦ Bounded polymorphism (“subtypes”)✦ Ad-hoc polymorphism (“some types”)

    • System F [Girard72,Reynolds74] =

    (simply-typed) lambda calculus+

    type abstraction & application

    195

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Polymorphism

    • Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    196

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    System F -- Syntax

    197

    Introduction

    System-F on one page

    Syntaxt ::=x | v | t t | t[T ]v ::=λx :T .t| ΛX .tT ::=X |T �T |∀X .T

    Evaluation rules

    E-AppFunt1 → t1�

    t1 t2 → t1� t2

    E-AppArgt → t �

    v t → v t �

    E-AppAbs(λx :T .t) v → [v/x ]t

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing rules

    T-Variablex : T ∈ ΓΓ � x : T

    T-AbstractionΓ, x : T � u : U

    Γ � λx : T .u : T → UT-ApplicationΓ � t : U → T Γ � u : U

    Γ � t u : TT-TypeAbstraction

    Γ,X � t : TΓ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    7 / 50

    Type application

    Type abstraction

    Polymorphic type

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    System F -- Typing rules

    198

    Introduction

    System-F on one page

    Syntaxt ::=x | v | t t | t[T ]v ::=λx :T .t| ΛX .tT ::=X |T �T |∀X .T

    Evaluation rules

    E-AppFunt1 → t1�

    t1 t2 → t1� t2

    E-AppArgt → t �

    v t → v t �

    E-AppAbs(λx :T .t) v → [v/x ]t

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing rules

    T-Variablex : T ∈ ΓΓ � x : T

    T-AbstractionΓ, x : T � u : U

    Γ � λx : T .u : T → UT-ApplicationΓ � t : U → T Γ � u : U

    Γ � t u : TT-TypeAbstraction

    Γ,X � t : TΓ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    7 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    System F -- Evaluation rules

    199

    Introduction

    System-F on one page

    Syntaxt ::=x | v | t t | t[T ]v ::=λx :T .t| ΛX .tT ::=X |T �T |∀X .T

    Evaluation rules

    E-AppFunt1 → t1�

    t1 t2 → t1� t2

    E-AppArgt → t �

    v t → v t �

    E-AppAbs(λx :T .t) v → [v/x ]t

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing rules

    T-Variablex : T ∈ ΓΓ � x : T

    T-AbstractionΓ, x : T � u : U

    Γ � λx : T .u : T → UT-ApplicationΓ � t : U → T Γ � u : U

    Γ � t u : TT-TypeAbstraction

    Γ,X � t : TΓ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    7 / 50

    Introduction

    System-F on one page

    Syntaxt ::=x | v | t t | t[T ]v ::=λx :T .t| ΛX .tT ::=X |T �T |∀X .T

    Evaluation rules

    E-AppFunt1 → t1�

    t1 t2 → t1� t2

    E-AppArgt → t �

    v t → v t �

    E-AppAbs(λx :T .t) v → [v/x ]t

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing rules

    T-Variablex : T ∈ ΓΓ � x : T

    T-AbstractionΓ, x : T � u : U

    Γ � λx : T .u : T → UT-ApplicationΓ � t : U → T Γ � u : U

    Γ � t u : TT-TypeAbstraction

    Γ,X � t : TΓ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    7 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Type abstraction and application

    200

    • Evaluation

    • Typing

    ✦ Type variables are in the environment.

    ✦ Type variables are subject to (implicit) renaming.

    Introduction

    New rules

    Evaluation

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing

    T-TypeAbstractionΓ, X � t : T

    Γ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    Note the type variables in the environmentFor now, just type variables, no binding to anythingSame conventions: must do renaming if a type variable name alreadybound

    8 / 50

    Introduction

    New rules

    Evaluation

    E-TypeAppt1 → t1�

    t1[T ] → t1�[T ]

    E-TypeAppAbs(ΛX .t)[T ] → [T/X ]t

    Typing

    T-TypeAbstractionΓ, X � t : T

    Γ � ΛX .t : ∀X .T

    T-TypeApplicationΓ � t : ∀X .T

    Γ � t[T1] : [T1/X ]T

    Note the type variables in the environmentFor now, just type variables, no binding to anythingSame conventions: must do renaming if a type variable name alreadybound

    8 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Examples

    201

    Term

    id =ΛX.λx :X.xid[bool]

    id[bool] true

    id true

    Type

    : ∀X.X →X: bool → bool: bool

    type error

    There is no type-argument deduction at this point.

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    The doubling functiondouble=ΛX.λf :X →X.λx :X.f (f x)

    202

    • Instantiated with natdouble_nat = double [nat]

    : (nat → nat) → nat → nat• Instantiated with nat → nat

    double_nat_arrow_nat = double [nat → nat]: ((nat → nat) → nat → nat) → (nat → nat) → nat → nat

    • Invoking double

    double [nat] (λx : nat.succ (succ x)) 5 →* 9

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Self application

    203

    • Not typeable in the simply-typed lambda calculus

    λx : ? . x x

    • Typeable in System F

    selfapp = λx : ∀X.X → X.x [∀X.X → X] x

    selfapp : (∀X.X → X) → (∀X.X → X)

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    The fix operator (Y)

    204

    • Not typeable in the simply-typed lambda calculus

    • Typeable in System F.

    fix : ∀X.(X → X) → X

    • Encodeable in System F with recursive types.

    fix = ?

    See [TAPL]

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Remember lists? (in the simply-typed lambda calculus)

    205

    • New type: ... | List T

    • New syntax: ... | nil[T] | const[T] t t | isnil[T] t | head[T] t | tail[T] t

    • New congruence rules, e.g.:

    • New computation rules, e.g.:

    • New typing rules, e.g.:

    Aside: general recursion

    Evaluating and typing lists

    Computation rules, just one example here, rest at home...

    head[S ] (cons[T ] v1 v2)→ v1

    Typing rules. Again, one example, rest at home....

    Γ � t : List TΓ � head[T ] t : T

    Both fix and lists were extensions to simply typed lambda calculus,with their own special typing and evaluation rules

    19 / 50

    Aside: general recursion

    Evaluating and typing lists

    Computation rules, just one example here, rest at home...

    head[S ] (cons[T ] v1 v2)→ v1

    Typing rules. Again, one example, rest at home....

    Γ � t : List TΓ � head[T ] t : T

    Both fix and lists were extensions to simply typed lambda calculus,with their own special typing and evaluation rules

    19 / 50

    Aside: general recursion

    Lists

    New type: List TNew syntax

    nil[T]cons[T] t tisnil[T] thead[T] ttail[T] t

    Congruence rules...

    t1 → t �1cons[T ] t1 t2 → cons[T ] t �1 t2

    do the rest at home...18 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Lists in System F

    206

    • Types of list operationsnil : ∀X. List X

    cons :∀X.X → List X → List X isnil

    : ∀X.List X → bool head : ∀X.List X → X tail : ∀X.List X → List X

    • List T can be encoded.∀X. (T → U → U) → U → U(see [TAPL] Chapter 23.4; requires fix)

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Meaning of “forall”

    207

    • Predicative polymorphism✦ X ranges over simple types.✦ Polymorphic types are “type schemes”.✦ Type inference is decidable.

    • Impredicative polymorphism✦ X also ranges over polymorphic types.✦ Type inference is undecidable.

    • type:type polymorphism✦ X ranges over all types, including itself.✦ Computations on types are expressible. ✦ Type checking is undecidable.

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

    In a universal type, ∀X. ..., we quantify over all types.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Limits of type schemes

    • Consider the polymorphic identity function:id : ∀X. X→Xid = ΛX.λx : X.x

    • Use id to construct a pair of Boolean and String:pairid : (Bool, String)

    pairid = (id true, id “true”)

    • Abstract over id:pairapply : (∀X. X→X) → (Bool, String)pairapply = λf : ∀X. X→X. (f true, f “true”)

    208

    Type application left implicit.

    Argument must be polymorphic!

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Existential types

    209

    • A means for information hiding and abstraction.

    • Remember predicate logic.

    • Existential types can be encoded as universal types; see [TAPL].

    • Syntax: {∃X, T}

    Existential types

    Existential types

    Existential types are a means for information hiding and abstractionNot a strict extension, remember from predicate logic:

    ∀x .P(x) ≡ ¬(∃x .¬P(x))

    Indeed, existential types can be encoded as universal typesSyntax:

    {∃X , T}

    31 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    ∀ vs. ∃

    210

    • t of type ∀X.T✦ Logical view: t has value of type [S/X]T for any S.✦ Operational view:

    t is a mapping from type S to a term of type [S/X]T.

    • t of type {∃X, T}✦ Logical view: t has value of type [S/X]T for some S.✦ Operational view:

    ★ t is a pair of a type S and a term u of type [S/X]T.★ S is hidden.★ Notation: { *S, u }

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Constructing existentials { *S, u }

    211

    • { *S, u } should be considered a package (module).

    • The type system makes sure that S is inaccessible from outside.

    • Consider the following package:

    p = {*nat, {a = 1, b = λx:nat. pred x}}• Multiple types make sense:

    ✦ { ∃X, {a:X, b:X → X} }✦ { ∃X, {a:X, b:X → nat} }

    • Existential types require programmer annotation.

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Annotating existentials

    212

    • p = {*nat, {a = 1, b = λx:nat. pred x}} as {∃X, {a:X, b:X → X}}

    p has type: { ∃X, {a:X, b:X → X}}

    • p’ = {*nat, {a = 1, b = λx:nat. pred x}} as {∃X, {a:X, b:X → nat}}

    p’ has type: { ∃X, {a:X, b:X → nat}}

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Information hiding

    • p1 = {*nat, {a = 1, b = λx:nat. iszero x}}

    as

    {∃X ,

    {a:X ,

    b:X → bool}}

    • p2 = {*bool, {a = false, b = λx:bool. if x then false else true}}

    as

    {∃X ,

    {a:X ,

    b:X → bool}}

    213

    Packages with different representation types can have the same existential type.

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Unpacking existentials(Opening package, importing module)

    • The existential becomes available.

    • The representation type is not accessible.

    • Only the capabilities of the existential type are accessible.

    • Example:

    let {X,t} = p2 in (t.b t.a) →* true : bool

    214

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Typing rules

    215

    Existential types

    Typing rules

    T-PackExistentialΓ � t : [U/X ]T

    Γ � {∗U, t} as {∃X , T} : {∃X , T}

    The big thing of existentials is that packages with differentrepresentation types can have the same existential type

    This is what gives information hidingExample

    p1 = {*nat, {a = 1, b = λx:nat. iszero x}}as {∃X, {a:X, b:X → bool}}

    p2 = {*bool, {a = false,b = λx:bool. if x then false else true}}

    as {∃X, {a:X, b:X → bool}}

    36 / 50

    Existential types

    Elimination rule

    T-UnpackExistentialΓ � t1 : {∃X , T12} Γ, X , x : T12 � t2 : T2

    Γ � let {X , x} = t1 in t2 : T2

    Unpacking an existential is comparable to importing or opening a

    module/package

    The existential becomes available but the representation type is not

    accessible

    Only the capabilities of the existential type are accessible

    Example

    let {X,t} = p2 in (t.b t.a)

    $> true : bool

    37 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

    Substitution checks that the abstracted type of t can be instantiated with the hidden type to the

    actual type of t.

    Only expose abstract type!

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Evaluation rules

    216

    Existential types

    Evaluation rules

    E-Packt → t �

    {∗T , t} as U → {∗T , t �} as UE-Unpack

    t1 → t �1let {X , x} = t1 in t2 → let {X , x} = t �1 in t2

    E-UnpackPacklet {X , x} = ({∗T , v} as U) in t2 → [T/X ][v/x ]t2

    The last rule is like module linking: symbolic names are replaced withthe concrete componentsNote: an expression can get a more exact type with evaluationEvaluation rules don’t care about typing, an ill-typed expression couldbe evaluated to a well-typed one

    38 / 50

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

    The hidden type is known to the evaluation, but the type system did not expose it; so t2 cannot exploit it.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Illustration of information hiding

    • The representation type must not leak / must remain abstract.

    t = {*nat, {a = 1, b = λx:nat. iszero x} as {∃ X, {a:X, b:X → bool}}}

    let {X,x} = t in pred x.a

    // Type error!

    • The type can be used in the scope of the unpacked package.

    let {X, x} = t in (λ y:X. x.b y) x.a →* false : bool

    • The type cannot be free in the resulting type:

    let {X, x} = t in x.a

    // Type error!

    217

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Polymorphism

    • Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    218

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    • We say S is a subtype of T.

    S

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Why subtyping• Function in near-to-C: void foo( struct { int a; } r) { r.a = 0; }

    • Function application in near-to-C: struct K { int a; int b: } K k; foo(k); // error

    • Intuitively, it is safe to pass k.Subtyping allows it.

    220

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subsumption

    • Subsititutability is captured with the subsumption rule:

    • Adding this rules requires revisiting other rules.

    Subtyping is a crosscutting extension.

    221

    Subtype relation

    Subsumption

    Subsititutability is captured with the following subsumption rule:

    Γ � t : U U

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping in simplified setting

    • Simply-typed lambda calculus +

    ✦ records

    ✦ Booleans

    ✦ integers

    • Structural subtyping for records

    222

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping for records

    • Order of fields does not matter.

    • Example:

    223

    Subtype relation

    Subtyping for records

    Order of fields does not matter

    S-RecordPermutation{li : Ti i∈1...n} is a permutation of {kj : Uj j∈1...n}

    {li : Ti i∈1...n}

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping for records

    • We can always add new fields in the end.

    • Example:

    224

    Subtype relation

    Subtyping for records

    We can always add new fields in the end

    S-RecordNewFields{li : Ti i∈1...n+k}

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping for records

    • We can subject the fields to subtyping.

    • Example:

    225

    Subtype relation

    Subtyping for records

    We can subject the fields to subtyping:

    S-RecordElementsfor each i Ti

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    General rules for subtyping

    • Reflexivity

    • Transitivity

    • Example

    226

    Subtype relation

    General rules for subtyping

    Reflexivity

    T

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping and functions

    • Assume that a function f of the following type is expected:

    f :T → U

    • Then it is safe to pass an actual function g such that:

    g :T’ → U’

    T

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Subtyping and functions

    • Function subtyping

    ✦ covariant on return types

    ✦ contravariant on parameter types

    228

    Subtype relation

    Subtyping and functions

    T2

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Supertype of everything

    • T ::= ... | top

    ✦ The most general type

    ✦ The supertype of all types

    229

    Subtype relation

    Supertype of everything

    Often type systems with subtyping have the most general type, which

    is a supertype of all types

    T

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Remember type annotation?

    230

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

    • Syntax:

    t ::= ... | t as T

    • Typing rule:

    • Evaluation rules:

    Subtyping and other extensions

    Ascription

    Reminder. Type rules:

    Γ � t : TΓ � t as T : T

    Evaluation rules:

    t → ut as T → u as T

    v as T → v

    18 / 40

    Subtyping and other extensions

    Ascription

    Reminder. Type rules:

    Γ � t : TΓ � t as T : T

    Evaluation rules:

    t → ut as T → u as T

    v as T → v

    18 / 40

    Subtyping and other extensions

    Ascription

    Reminder. Type rules:

    Γ � t : TΓ � t as T : T

    Evaluation rules:

    t → ut as T → u as T

    v as T → v

    18 / 40

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Annotation is up-casting

    231

    Subtyping and other extensions

    Ascription

    Example

    ...Γ � t : U

    ...U

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Type annotation with down-casting

    232

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

    • Typing rule:

    • Evaluation rules:

    Subtyping and other extensions

    Ascription

    Reminder. Type rules:

    Γ � t : TΓ � t as T : T

    Evaluation rules:

    t → ut as T → u as T

    v as T → v

    18 / 40

    Subtyping and other extensions

    Down-casting typing and evaluation rules

    Typing rule

    Γ � t : UΓ � t as T : T

    Remember the evaluation rules:

    t → ut as T → u as T

    v as T → v

    Is this right? What’s the effect on preservation?

    22 / 40

    Potentially too liberal

    Subtyping and other extensions

    Down-casting typing and evaluation rules

    Typing rule

    Γ � t : UΓ � t as T : T

    Remember the evaluation rules:

    t → ut as T → u as T

    � v : Tv as T → v

    Note, that this type condition on evaluation relation is a checkperformed at run-timeWhat is the effect on progress?

    23 / 40

    Runtime type check

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Typing rules so far

    233

    About subtyping

    Typing rules so far

    T-Recordfor each i , Γ � ti : Ti

    Γ � {li = ti i∈1...n} : {li : Ti i∈1...n}

    T-ProjectionΓ � t : {li : Ti i∈1...n}

    Γ � t.lj : TjT-SubsumptionΓ � t : U U

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Reminder

    234

    A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. [B.C. Pierce]

    This slide is derived from Jaakko Järvi’s slides for his course ”Programming Languages”, CPSC 604 @ TAMU.

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Violation of syntax direction

    • Consider an application:

    t u where

    t of type U → V and u of type S.

    • Type checker must figure out that S

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Analysis of subsumption

    236

    • The term in the conclusion can be anything.

    It is just a metavariable.

    • E.g. which rule should you apply here?

    T-Abstraction or T-Subsumption?

    About subtyping

    Closer look at subsumption rule

    T-SubsumptionΓ � t : U U

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Analysis of transitivity

    237

    • U does not appear in conclusion.

    Thus, to show T

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Analysis of transitivity

    238

    • What is the purpose of transitivity?

    Chaining together separate subtyping rules for records!

    Subtype relation

    Subtyping for records

    Order of fields does not matter

    S-RecordPermutation{li : Ti i∈1...n} is a permutation of {kj : Uj j∈1...n}

    {li : Ti i∈1...n}

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Algorithmic subtyping• Replace all previous rules by a single rule.

    • Correctness / completeness of new rule can be shown.

    • Maintain extra rule for function types.

    239

    About subtyping

    Algorithmic subtyping

    Transitivity was to chain together the three record subtyping rulesWe can replace all three by just one syntax directed rule

    S-Record{li i∈1...n} ⊆ {kj j∈1...m} li = kj implies Ui

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    Algorithmic subtyping

    • The subsumption rule is still not syntax-directed.

    • The rule is essentially used in function application.

    • Express subsumption through an extra premise.

    • Retire subsumption rule.

    240

    About subtyping

    Algorithmic typing

    Similar problems remain with the subsumption rule — it is not syntaxdirectedWhere is subsumption needed?

    (λx : {b : B}. x .b) {a = someA, b = someB}

    This is the only place where it is essentialSubsumption can be dropped if the function application rule ismodified

    T-ApplicationΓ � t : U → T Γ � u : V V

  • © Ralf Lämmel, 2009-2011 unless noted otherwise

    • Summary: Lambdas with somewhat sexy types✦ Done: ∀,∃,