lambda calculi with polymorphism - uni koblenz-landaulaemmel/plt/slides/... · 2012. 12. 12. ·...

of 48 /48
x = 1 let x = 1 in ... x(1). !x(1) x.set(1) Lambda Calculi With Polymorphism Ralf Lämmel Programming Language Theory 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

Author: others

Post on 09-Apr-2021

1 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 Language Theory

    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

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

    Polymorphism -- Why?

    • What’s the identity function?

    • In the simply typed lambda calculus, we need many!

    • Examples

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

    87

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

    In need of polymorphic functions, i.e., functions that accept many types of arguments.

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

    Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    ✦ Existential types (“exists as opposed to for all”)

    88

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

    Font size correlates with

    coverage in lecture.

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

    Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    ✦ Existential types (“exists as opposed to for all”)

    89

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

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

    System F -- Syntax

    90

    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.

    System F [Girard72,Reynolds74] =

    (simply-typed) lambda calculus

    +

    type abstraction & application

    Type variable

    Example:id : ∀X.X →Xid =ΛX.λx :X.x

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

    System F -- Typing rules

    91

    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.

    Type variables are held the

    context.

    Type variables are subject to

    alpha conversion.

    Example:id : ∀X.X →Xid =ΛX.λx :X.x

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

    System F -- Evaluation rules

    92

    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.

    Example:id : ∀X.X →Xid =ΛX.λx :X.x

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

    Examples

    93

    Term

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

    id[bool] true

    id true

    Type

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

    type error

    In actual programming languages, type application may be implicit.

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

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

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

    94

    • 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-2012 unless noted otherwise

    Functions on polymorphic functions

    • 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”)

    95

    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-2012 unless noted otherwise

    Self application

    96

    • Not typeable in the simply-typed lambda calculus

    λx : ? . x x

    • Typeable in System F

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

    selfapp = λx : ∀X.X → 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-2012 unless noted otherwise

    The fix operator (Y)

    97

    • Not typeable in the simply-typed lambda calculus

    ✦ Extension required

    • 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.

    Aside: general recursion

    The fix operator

    We discussed the fix point operator (Y-combinator, fix), and showedits definition in untyped lambda calculusJust like self-application, fix cannot be typed in simply-typed lambdacalculusSimple fix: add fix as a primitive

    fix (λx : T .t)→ [(fix (λx : T .t))/x ] t

    t → t �

    fix t → fix t �

    Γ � t : T → TΓ � fix t : T

    16 / 50

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

    Meaning of “all types”

    98

    • 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 the type ∀X. ..., we quantify over “all types”.

    Not covered by this lecture

    Generality is used for selfapp.

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

    Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    ✦ Existential types (“exists as opposed to for all”)

    99

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

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

    • We say S is a subtype of T.

    S

  • © Ralf Lämmel, 2009-2012 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.

    101

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

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

    Subsumption(Subsititutability of supertypes by subtypes)

    102

    Subtype relation

    Subsumption

    Subsititutability is captured with the following subsumption rule:

    Γ � t : U U

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

    Structural subtyping for records

    • A subtype may have additional label/type pairs.

    • A subtype may permute the label/type pairs.

    • A subtype may use subtypes for label/type pairs.

    103

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

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

    A subtype may have additional label/type pairs.

    104

    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-2012 unless noted otherwise

    A subtype may permute the label/type pairs.

    105

    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-2012 unless noted otherwise

    A subtype may use subtypes for label/type pairs.

    106

    Subtype relation

    Subtyping for records

    We can subject the fields to subtyping:

    S-RecordElementsfor each i Ti

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

    General rules for subtyping

    • Subsumption

    • Reflexivity of subtyping

    • Transitivity of subtyping

    • Subtyping for function types

    • Supertype of everything

    • Up and down cast

    107

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

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

    General rules for subtyping

    • Reflexivity

    • Transitivity

    • Example which needs transitivity

    108

    Subtype relation

    General rules for subtyping

    Reflexivity

    T

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

    Subtyping of functions

    • Subsumption provides subtyping for function arguments and results.

    • An additional rule is needed to provide subtyping for function types.

    • Compare this to the need for subtyping rules for record types.

    • Consider the following function application:

    (λf : {a:int, b:int} → {c:int} . f {a:42, b:88}) g• Several types can be permitted for g:

    ✦ g : {a:int, b:int} → {c:int}✦ g : {a:int} → {c:int, d:int}✦ ...

    109

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

    The actual function may “use” less fields and “return”

    more fields.

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

    Subtyping of functions

    • Function subtyping

    ✦ covariant on return types

    ✦ contravariant on parameter types

    110

    Subtype relation

    Subtyping and functions

    T2

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

    Supertype of everything

    • T ::= ... | top

    ✦ The most general type

    ✦ The supertype of all types

    111

    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-2012 unless noted otherwise

    Remember type annotation?

    112

    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-2012 unless noted otherwise

    • Illustrative type derivation:

    • Example:

    Annotation as up-casting

    113

    Subtyping and other extensions

    Ascription

    Example

    ...Γ � t : U

    ...U

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

    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

    Annotation as down-casting

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

    Algorithmic subtyping

    115

    Reminder: 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.

    We violate this definition because some rules are not “syntax-driven”!

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

    Violation of syntax direction

    • Consider an application:

    t u where

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

    • A type checker would need to figure out that S

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

    Analysis of subsumption

    117

    • The term in the conclusion can be anything.

    It is just a metavariable.

    • Example: 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-2012 unless noted otherwise

    Analysis of transitivity

    118

    • U does not appear in conclusion.

    Thus, to show T

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

    Analysis of transitivity

    119

    • 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-2012 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.

    120

    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-2012 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.

    121

    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-2012 unless noted otherwise

    Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    ✦ Existential types (“exists as opposed to for all”)

    122

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

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

    Kinds of polymorphism

    ✦ Parametric polymorphism (“all types”)

    ✦ Bounded polymorphism (“subtypes”)

    ✦ Ad-hoc polymorphism (“some types”)

    ✦ Existential types (“exists as opposed to for all”)

    123

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

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

    Universal versus existential quantification

    124

    • Existential types serve a specific purpose:

    A means for information hiding (encapsulation).

    • Remember predicate logic.

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

    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.

    “∃” will not show up in the exam! However, it’s very healthy to know this stuff!

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

    Overview

    • Syntax of types:

    T ::= ···

    | {∃X, T}

    • Normal forms:

    v ::= ···

    | { *T, v }

    • Terms:

    t ::= ···

    | { *T, t } as T

    | let {X, x} = t in t

    125

    Hidden type

    Package with type

    Unpacking

    Package

    Existentially quantified type

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

    Constructing existentials

    126

    • A record:

    r : { a : nat, b : nat → nat }

    r = { a = 1, b = λ x : nat . pred x }

    • A package with nat as hidden type:

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

    p = { *nat, r }

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

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

    Illustration of using the record:

    r. b r.a

    In fact, we need to “assign” this or another type.

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

    • r : { a : nat, b : nat → nat }

    r = { a = 1, b = λ x : nat . pred x }

    • p = {*nat, r } as {∃X, {a:X, b:X → X}}

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

    • p’ = {*nat, r } 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.

    Multiple types make sense for the package. Hence, the programmer must provide an annotation upon construction.

    “preferred”

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

    • 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}}

    128

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

    We can have the same existential type with different

    representation types.

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

    Unpacking existentials(Opening package, importing module)

    • Example -- apply b to a:

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

    • Syntax:

    let {X,x} = t in t’

    ✦ The value x of the existential becomes available.

    ✦ The representation type is not accessible (only X).

    129

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

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

    Typing rules

    130

    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 of existential!

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

    Evaluation rules

    131

    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-2012 unless noted otherwise

    Illustration of information hiding

    • 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 representation type 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 must not leak into the resulting type:

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

    // Type error!

    132

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

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

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