Languages, Programming CPSC 604--Slides 13
Bounded Quantification
Jaakko Jrvi
April 9, 2009
1 / 32
Introduction
Outline
1
Introduction
2
Why F-bounds?
2 / 32
Introduction
Bounded quantification
Combining subtyping and polymorphism Straightforward but uninteresting idea: keep both orthogonal Following two examples demonstrate why this is not adequate
3 / 32
Introduction
Example 1
rec_a_id = x:{a:nat}. x; %> rec_a_id : {a:nat} {a:nat} rec_a_id {a=1} %> {a=1} : {a:nat} rec_a_id {a=1, b=true} // this is ok, // {a:nat, b:bool} <: {a:nat} %> {a=1, b=true} : {a:nat} (rec_a_id {a=1, b=true}).b // error!
4 / 32
Introduction
Example 1
rec_a_id = x:{a:nat}. x; %> rec_a_id : {a:nat} {a:nat} rec_a_id {a=1} %> {a=1} : {a:nat} rec_a_id {a=1, b=true} // this is ok, // {a:nat, b:bool} <: {a:nat} %> {a=1, b=true} : {a:nat} (rec_a_id {a=1, b=true}).b // error!
Subtyping allows functions to work with more than one type, but some type information is lost with subsumption
4 / 32
Introduction
Example 1
Polymorphic types come to rescue. Now poly_id works for all types, and returns the same type as the incoming type: poly_id = T . x:T. x; %> poly_id : T. T T poly_id [{a:nat, b=bool}] {a=1, b:true} %> {a=1, b=true} : {a:nat, b=bool}
5 / 32
Introduction
Example 1
Polymorphic types come to rescue. Now poly_id works for all types, and returns the same type as the incoming type: poly_id = T . x:T. x; %> poly_id : T. T T poly_id [{a:nat, b=bool}] {a=1, b:true} %> {a=1, b=true} : {a:nat, b=bool} However, no operations on the parameterized types are possible...
5 / 32
Introduction
Example 2
Consider the following, where a "non-parametric" operation is performed to the argument of the function rec_a_next = x:{a:nat}. {old=x, next=(succ x.a)}; %> rec_a_next : {a:nat} {old:{a:nat}, next:nat} rec_a_next {a=1} %> {old={a=1},next=2} : {old:{a:nat}, next:nat} rec_a_next {a=1, b=true} %> {old={a=1,b=true},next=2} : {old:{a:nat}, next:nat}
6 / 32
Introduction
Example 2
Consider the following, where a "non-parametric" operation is performed to the argument of the function rec_a_next = x:{a:nat}. {old=x, next=(succ x.a)}; %> rec_a_next : {a:nat} {old:{a:nat}, next:nat} rec_a_next {a=1} %> {old={a=1},next=2} : {old:{a:nat}, next:nat} rec_a_next {a=1, b=true} %> {old={a=1,b=true},next=2} : {old:{a:nat}, next:nat} Attempt to fix this with type abstraction fails: poly_a_next = T. x:T. {old=x, next=(succ x.a)}; %> error!
6 / 32
Introduction
Example 2
Consider the following, where a "non-parametric" operation is performed to the argument of the function rec_a_next = x:{a:nat}. {old=x, next=(succ x.a)}; %> rec_a_next : {a:nat} {old:{a:nat}, next:nat} rec_a_next {a=1} %> {old={a=1},next=2} : {old:{a:nat}, next:nat} rec_a_next {a=1, b=true} %> {old={a=1,b=true},next=2} : {old:{a:nat}, next:nat} Attempt to fix this with type abstraction fails: poly_a_next = T. x:T. {old=x, next=(succ x.a)}; %> error! We want to qualify "for all" somehow This is where we mix subtyping and universal types
6 / 32
Introduction
Bounded quantification: System F<:
poly_a_next2 = T<:{a:nat}. x:T. {old=x, next=(succ x.a)}; poly_a_next2 : T<:{a:nat}. T {old:T, next:nat}; All quantifiers (universal and existential) can carry subtype constraints Two systems: kernel F<: and full F<:
7 / 32
Introduction
Kernel F<:
Syntax t ::=x | v | t t v ::=x : T .t | X <: T .t | t[T ] T ::=X | T T | X <: T .T | top Typing rules
T-Variable
x :T x :T
T-Abstraction
, x : T u:U x : T .u : T U
::= | , x : T | , X <: T Evaluation rules
T-Application
t:UT u:U t u:T
E-AppFun
t1 t1 t1 t2 t1 t2
E-AppArg
tt v tv t
T-TypeAbstraction
, X <: T1 t : T2 X <: T1 .t : X <: T1 .T2
E-AppAbs
(x : T .t) v [v /x]t
T-TypeApplication
t : X <: T1 .T2 U <: T1 t[U] : [U/X ]T2
E-TypeApp
t1 t1 t1 [T ] t1 [T ]
E-TypeAppAbs
(X <: T1 .t)[T2 ] [T2 /X ]t
T-Subsumption
t:S S <: T t:T
8 / 32
Introduction
Kernel F<: continues
S-Reflexivity
T <: T
S-Transitivity
T <: U U <: V T <: V
S-Top
T <: top
S-Function
T1 <: T2 T2 U1 <: U2 U2 U1 <: T1
S-TVar
X <: T X <: T
S-All
, X <: U S <: T X <: U.S <: X <: U.T
9 / 32
Introduction
Bounded vs. unbounded quantification
Is parametric polymorphism still possible? What happened to the rules where no quantification is used?
10 / 32
Introduction
Bounded vs. unbounded quantification
Is parametric polymorphism still possible? What happened to the rules where no quantification is used? A type parameter without a bound is just syntactic sugar for a type parameter with top as the bound X .T = X <: top.T
def
10 / 32
Introduction
Well typed contexts
In t : T both t and T can contain free type variables, which must be bound in Types in can contain free type variables too! Different interpretations of scoping within the environment The book discusses a restrictive variant Practical languages (C#, Java, Eiffel) have adopted more flexible (but each different) rules
11 / 32
Introduction
Scoping in typing context
Is this context well typed? 1 = X<:top, y:X nat
12 / 32
Introduction
Scoping in typing context
Is this context well typed? Yes 1 = X<:top, y:X nat Could arise e.g. from typing the following term X<:top. y:X nat. t
12 / 32
Introduction
Scoping in typing context
Is this context well typed? Yes 1 = X<:top, y:X nat Could arise e.g. from typing the following term X<:top. y:X nat. t How about this? 2 = y:X nat, X<:top
12 / 32
Introduction
Scoping in typing context
Is this context well typed? Yes 1 = X<:top, y:X nat Could arise e.g. from typing the following term X<:top. y:X nat. t How about this? No 2 = y:X nat, X<:top Could arise e.g. from typing the following term (where first X is not bound) y:X nat. X<:top. t
12 / 32
Introduction
Scoping in typing context
Are these well-typed contexts? 3 4 5 6 = = = = X<:{a:nat, b:X} X<:{a:nat, b:Y}, Y<:{c:bool, d:X} Y<:{a:nat, b:Y}, X<:Y Y<:X, X<:Y
13 / 32
Introduction
Scoping in typing context
Are these well-typed contexts? 3 4 5 6 = = = = X<:{a:nat, b:X} X<:{a:nat, b:Y}, Y<:{c:bool, d:X} Y<:{a:nat, b:Y}, X<:Y Y<:X, X<:Y
3 is F-bounded polymorphism, the rest its extensions
13 / 32
Introduction
Scoping in typing context
Are these well-typed contexts? 3 4 5 6 = = = = X<:{a:nat, b:X} X<:{a:nat, b:Y}, Y<:{c:bool, d:X} Y<:{a:nat, b:Y}, X<:Y Y<:X, X<:Y
3 is F-bounded polymorphism, the rest its extensions C#, Eiffel, Java, Fortress allow all
13 / 32
Introduction
Scoping in typing context
Are these well-typed contexts? 3 4 5 6 = = = = X<:{a:nat, b:X} X<:{a:nat, b:Y}, Y<:{c:bool, d:X} Y<:{a:nat, b:Y}, X<:Y Y<:X, X<:Y
3 is F-bounded polymorphism, the rest its extensions C#, Eiffel, Java, Fortress allow all F-bounded quantification crucial for typing binary methods
13 / 32
Introduction
Full F<:
The kernel rule S-All: , X <: U X <: U.S S <: T <: X <: U.T
Consider bounded-polymorphic types A and B. A<:B if both have the same type parameter and bound, and "body" of A is a subtype of the body B. subtype relation
The full rule S-All: T1 <: S1 , X <: T1 S2 <: T2
X <: S1 .S2 <: X <: T1 .T2
A<:B if both have the same type parameter and its constraint in A is weaker than in B (bound of B subtype of bound of A), and "body" of A is a subtype of the body B.
14 / 32
Introduction
Example
Consider the code: a = X<:B. x:X. {u=x}; b = X<:B. x:X. {u=x, v=x}; a : TA = X<:B. {u:X} b : TB = X<:B. {u:X, v:X} Here, TB <: TA in both systems Assume below that B<:A a b a b = = : : X<:B. x:X. {u=x}; X<:A. x:X. {u=x, v=x}; TA = X<:B. {u:X} TB = X<:A. {u:X, v:X}
TB <: TA in full F<: , but not in the kernel variant
15 / 32
Introduction
Similar examples in Java
Bounds do not change
public class a<X extends B> { X u; } public class b<X extends B> extends a<X> { X v; }
Bounds change
public class A {} public class B extends A {} public class a<X extends B> { X u; } public class b<X extends A> extends a<X> { // error X v; }
16 / 32
Introduction
Similar examples in Java
Bounds do not change
public class a<X extends B> { X u; } public class b<X extends B> extends a<X> { X v; }
Bounds change
public class A {} public class B extends A {} public class a<X extends B> { X u; } public class b<X extends A> extends a<X> { // error X v; }
No feature to demonstrate full vs. kernel really
16 / 32
Introduction
Full vs. Kernel in Java context
Replacing the definition of A1<X extends V> with A1<X extends U> is OK (if the body of A1 stays well-formed) class U {} class V extends U {} class A1<T extends V > { public Integer a; } // can A2 accept all instantiations that A1 can? class A2 <T extends U> { public Integer a; } ... (new A1<V>()).a 5; = (new A2<V>()).a = 5;
17 / 32
Why F-bounds?
Outline
1
Introduction
2
Why F-bounds?
18 / 32
Why F-bounds?
A long example without a single !
We use the following C++-like syntax to demonstrate why plain bounded quantification is not adequate struct point { int x; int y; }; struct color_point : public point { int color; }; This establishes color_point <: point A foundational paper: Peter Canning, William Cook, Walter Hill, Walter Olthoff, and John C. Mitchell. F-bounded polymorphism for object-oriented programming. Functional Programming Languages and Computer Architecture, pages 273280, ACM, 1989.
19 / 32
Why F-bounds?
Subtyping example
struct point { int x; int y; }; struct color_point : public point { int color; }; point move(point a, int dx, int dy) { a.x += dx; a.y += dy; return a; } int main () { point p; p.x = 0; p.y = 0; p = move(p, 1, 2); assert(p.x == 1 && p.y == 2); color_point cp; cp.x = 0; cp.y = 0; cp.color = 0; p = move(cp, 1, 2); assert(p.x == 1 && p.y == 2); return 0; };
With just subtyping, the exact type of cp is lost when passed in to and out from move()
20 / 32
Why F-bounds?
Let's try
struct point { int x; int y; }; struct color_point : public point { int color; }; point move(point a, int dx, int dy) { a.x += dx; a.y += dy; return a; } int main () { color_point cp; cp.x = 0; cp.y = 0; cp.color = 0; cp = move(cp, 1, 2); return 0; }
21 / 32
Why F-bounds?
Let's try
struct point { int x; int y; }; struct color_point : public point { int color; }; point move(point a, int dx, int dy) { a.x += dx; a.y += dy; return a; } int main () { color_point cp; cp.x = 0; cp.y = 0; cp.color = 0; cp = move(cp, 1, 2); return 0; }
fail_point_color_point_subtyping.cpp: In function 'int main()': fail_point_color_point_subtyping.cpp:9: error: no match for 'operator=' in 'cp = move(cp.color_point::<anonymous>, 1, 2)' fail_point_color_point_subtyping.cpp:2: note: candidates are: color_point& color_point::operator=(const color_point&)
21 / 32
Why F-bounds?
Bounded quantification
We know that a possible fix to this lost of type accuracy is to use parametric polymorphism (instead of subtype polymorphism): template <class T> T move(T a, int dx, int dy) { a.x += dx; a.y += dy; return a; }; This works in C++: cp = move(cp, 1, 2);
22 / 32
Why F-bounds?
Bounded quantification
We know that a possible fix to this lost of type accuracy is to use parametric polymorphism (instead of subtype polymorphism): template <class T> T move(T a, int dx, int dy) { a.x += dx; a.y += dy; return a; }; This works in C++: cp = move(cp, 1, 2); ... but how can it? move is not intrinsically a parametric function? Its body's working depends on properties of the type parameters
22 / 32
Why F-bounds?
Bounded quantification
We know that a possible fix to this lost of type accuracy is to use parametric polymorphism (instead of subtype polymorphism): template <class T> T move(T a, int dx, int dy) { a.x += dx; a.y += dy; return a; }; This works in C++: cp = move(cp, 1, 2); ... but how can it? move is not intrinsically a parametric function? Its body's working depends on properties of the type parameters
Constraints are implicit
22 / 32
Why F-bounds?
Bounded quantification
Temporarily, let us invent new syntax for C++ to express subtype constraints... template <class T <: point> T move(T a, int dx, int dy) { a.x += dx; a.y += dy; return a; }; The type of this function would be something like: T <: point.(T, int, int) T Compare to the type of the non-generic move: point move(point a, int dx, int dy) { a.x += dx; a.y += dy; return a; } (point, int, int) point
23 / 32
Why F-bounds?
... bounded quantification
[Cardelli, Wegner 85] Bounded quantification t.t <: . [t] where t does not occur in . The essence of the restriction is, that constraint is fixed for all instantiations. Generalizes to multiple type variables. t1 .t1 <: 1 .(t2 .t2 <: 2 . [t1 , t2 ])
24 / 32
Why F-bounds?
Problems with bounded quantification
Move over to C# now... interface Movable { Movable move(int x, int y); } Define function translate that takes any Movable object, and returns another one of the same type, moved one unit along both axis. translate should have (roughly) the type: T <: Movable.T T First attempt T translate<T>(T m) where T : Movable { return m.move(1, 1); }
25 / 32
Why F-bounds?
Problems with bounded quantification
Move over to C# now... interface Movable { Movable move(int x, int y); } Define function translate that takes any Movable object, and returns another one of the same type, moved one unit along both axis. translate should have (roughly) the type: T <: Movable.T T First attempt T translate<T>(T m) where T : Movable { return m.move(1, 1); } // typing error! move is (roughly) of type (Movable, int, int) Movable
25 / 32
Why F-bounds?
Problems with bounded quantification
Move over to C# now... interface Movable { Movable move(int x, int y); } Define function translate that takes any Movable object, and returns another one of the same type, moved one unit along both axis. translate should have (roughly) the type: T <: Movable.T T First attempt T translate<T>(T m) where T : Movable { return m.move(1, 1); } // typing error! move is (roughly) of type (Movable, int, int) Movable Essentially, we again hit the problem of subtyping losing information
25 / 32
Why F-bounds?
Binary method problem
Assume the...