lambda calculi with polymorphism - uni koblenz-landaulaemmel/plt/slides/... · 2012. 12. 12. ·...
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: ∀,∃,