lambda calculi with polymorphism · polymorphism •kinds of polymorphism parametric polymorphism...
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, 20092011 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, 20092011 unless noted otherwise
Polymorphism
• Polymorphic function✦ a function that accepts many types of arguments.
• Kinds of polymorphism✦ Parametric polymorphism (“all types”)✦ Bounded polymorphism (“subtypes”)✦ Adhoc polymorphism (“some types”)
• System F [Girard72,Reynolds74] =
(simplytyped) 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, 20092011 unless noted otherwise
Polymorphism
• Kinds of polymorphism
✦ Parametric polymorphism (“all types”)
✦ Bounded polymorphism (“subtypes”)
✦ Adhoc 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, 20092011 unless noted otherwise
System F  Syntax
197
Introduction
SystemF on one page
Syntaxt ::=x  v  t t  t[T ]v ::=λx :T .t ΛX .tT ::=X T �T ∀X .T
Evaluation rules
EAppFunt1 → t1�
t1 t2 → t1� t2
EAppArgt → t �
v t → v t �
EAppAbs(λx :T .t) v → [v/x ]t
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing rules
TVariablex : T ∈ ΓΓ � x : T
TAbstractionΓ, x : T � u : U
Γ � λx : T .u : T → UTApplicationΓ � t : U → T Γ � u : U
Γ � t u : TTTypeAbstraction
Γ,X � t : TΓ � ΛX .t : ∀X .T
TTypeApplicationΓ � 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, 20092011 unless noted otherwise
System F  Typing rules
198
Introduction
SystemF on one page
Syntaxt ::=x  v  t t  t[T ]v ::=λx :T .t ΛX .tT ::=X T �T ∀X .T
Evaluation rules
EAppFunt1 → t1�
t1 t2 → t1� t2
EAppArgt → t �
v t → v t �
EAppAbs(λx :T .t) v → [v/x ]t
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing rules
TVariablex : T ∈ ΓΓ � x : T
TAbstractionΓ, x : T � u : U
Γ � λx : T .u : T → UTApplicationΓ � t : U → T Γ � u : U
Γ � t u : TTTypeAbstraction
Γ,X � t : TΓ � ΛX .t : ∀X .T
TTypeApplicationΓ � 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, 20092011 unless noted otherwise
System F  Evaluation rules
199
Introduction
SystemF on one page
Syntaxt ::=x  v  t t  t[T ]v ::=λx :T .t ΛX .tT ::=X T �T ∀X .T
Evaluation rules
EAppFunt1 → t1�
t1 t2 → t1� t2
EAppArgt → t �
v t → v t �
EAppAbs(λx :T .t) v → [v/x ]t
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing rules
TVariablex : T ∈ ΓΓ � x : T
TAbstractionΓ, x : T � u : U
Γ � λx : T .u : T → UTApplicationΓ � t : U → T Γ � u : U
Γ � t u : TTTypeAbstraction
Γ,X � t : TΓ � ΛX .t : ∀X .T
TTypeApplicationΓ � t : ∀X .T
Γ � t[T1] : [T1/X ]T
7 / 50
Introduction
SystemF on one page
Syntaxt ::=x  v  t t  t[T ]v ::=λx :T .t ΛX .tT ::=X T �T ∀X .T
Evaluation rules
EAppFunt1 → t1�
t1 t2 → t1� t2
EAppArgt → t �
v t → v t �
EAppAbs(λx :T .t) v → [v/x ]t
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing rules
TVariablex : T ∈ ΓΓ � x : T
TAbstractionΓ, x : T � u : U
Γ � λx : T .u : T → UTApplicationΓ � t : U → T Γ � u : U
Γ � t u : TTTypeAbstraction
Γ,X � t : TΓ � ΛX .t : ∀X .T
TTypeApplicationΓ � 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, 20092011 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
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing
TTypeAbstractionΓ, X � t : T
Γ � ΛX .t : ∀X .T
TTypeApplicationΓ � 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
ETypeAppt1 → t1�
t1[T ] → t1�[T ]
ETypeAppAbs(ΛX .t)[T ] → [T/X ]t
Typing
TTypeAbstractionΓ, X � t : T
Γ � ΛX .t : ∀X .T
TTypeApplicationΓ � 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, 20092011 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 typeargument 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, 20092011 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, 20092011 unless noted otherwise
Self application
203
• Not typeable in the simplytyped 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, 20092011 unless noted otherwise
The fix operator (Y)
204
• Not typeable in the simplytyped 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, 20092011 unless noted otherwise
Remember lists? (in the simplytyped 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 unless noted otherwise
Typing rules
215
Existential types
Typing rules
TPackExistentialΓ � 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
TUnpackExistentialΓ � 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, 20092011 unless noted otherwise
Evaluation rules
216
Existential types
Evaluation rules
EPackt → t �
{∗T , t} as U → {∗T , t �} as UEUnpack
t1 → t �1let {X , x} = t1 in t2 → let {X , x} = t �1 in t2
EUnpackPacklet {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 illtyped expression couldbe evaluated to a welltyped 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, 20092011 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, 20092011 unless noted otherwise
Polymorphism
• Kinds of polymorphism
✦ Parametric polymorphism (“all types”)
✦ Bounded polymorphism (“subtypes”)
✦ Adhoc 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, 20092011 unless noted otherwise
• We say S is a subtype of T.
S

© Ralf Lämmel, 20092011 unless noted otherwise
Why subtyping• Function in neartoC: void foo( struct { int a; } r) { r.a = 0; }
• Function application in neartoC: 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, 20092011 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, 20092011 unless noted otherwise
Subtyping in simplified setting
• Simplytyped 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, 20092011 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
SRecordPermutation{li : Ti i∈1...n} is a permutation of {kj : Uj j∈1...n}
{li : Ti i∈1...n}

© Ralf Lämmel, 20092011 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
SRecordNewFields{li : Ti i∈1...n+k}

© Ralf Lämmel, 20092011 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:
SRecordElementsfor each i Ti

© Ralf Lämmel, 20092011 unless noted otherwise
General rules for subtyping
• Reflexivity
• Transitivity
• Example
226
Subtype relation
General rules for subtyping
Reflexivity
T

© Ralf Lämmel, 20092011 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, 20092011 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, 20092011 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, 20092011 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, 20092011 unless noted otherwise
Annotation is upcasting
231
Subtyping and other extensions
Ascription
Example
...Γ � t : U
...U

© Ralf Lämmel, 20092011 unless noted otherwise
Type annotation with downcasting
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
Downcasting 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
Downcasting 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 runtimeWhat is the effect on progress?
23 / 40
Runtime type check

© Ralf Lämmel, 20092011 unless noted otherwise
Typing rules so far
233
About subtyping
Typing rules so far
TRecordfor each i , Γ � ti : Ti
Γ � {li = ti i∈1...n} : {li : Ti i∈1...n}
TProjectionΓ � t : {li : Ti i∈1...n}
Γ � t.lj : TjTSubsumptionΓ � t : U U

© Ralf Lämmel, 20092011 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, 20092011 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, 20092011 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?
TAbstraction or TSubsumption?
About subtyping
Closer look at subsumption rule
TSubsumptionΓ � t : U U

© Ralf Lämmel, 20092011 unless noted otherwise
Analysis of transitivity
237
• U does not appear in conclusion.
Thus, to show T

© Ralf Lämmel, 20092011 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
SRecordPermutation{li : Ti i∈1...n} is a permutation of {kj : Uj j∈1...n}
{li : Ti i∈1...n}

© Ralf Lämmel, 20092011 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
SRecord{li i∈1...n} ⊆ {kj j∈1...m} li = kj implies Ui

© Ralf Lämmel, 20092011 unless noted otherwise
Algorithmic subtyping
• The subsumption rule is still not syntaxdirected.
• 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
TApplicationΓ � t : U → T Γ � u : V V

© Ralf Lämmel, 20092011 unless noted otherwise
• Summary: Lambdas with somewhat sexy types✦ Done: ∀,∃,