java type unification with wildcardspl/talks/wlp2007.pdf · 2011. 9. 29. · introduction subtyping...

IntroductionSubtyping in Java 5.0

Type unificationConclusion

Java Type Unification with Wildcards

Martin Plumicke

University of Cooperative EducationStuttgart/Horb

October 6, 2007

Martin Plumicke Java Type Unification with Wildcards

Overview

IntroductionMotivation

Subtyping in Java 5.0

Type unificationType Unification problemRelated workThe algorithm

Conclusion

Motivation

Extensions of the Java 5.0 type–systemI parameterized types, type variables, type terms, wildcards

Vector<? extends AbstractList<? super Integer>>

Complex typingsI Often it is not obvious, which are the best types for methods and

variables

I Sometimes principal types in Java 5.0 are intersection types, whichare not expressible (contradictive of writing re-usable code)

=⇒ Developing a type–inference–system, which determines principal types

Motivation

variables

Motivation

variables

Motivation

Example: Multiplication of matrices

class Matrix extends Vector<Vector<Integer>> {Matrix mul(Matrix m) {

Matrix ret = new Matrix();

int i = 0;

while(i <size()) {Vector<Integer> v1 = this.elementAt(i);

Vector<Integer> v2 = new Vector<Integer>();

int j = 0;

while(j < v1.size()) {int erg = 0;

int k = 0;

while(k < v1.size()) {erg = erg + v1.elementAt(k)

* m.elementAt(k).elementAt(j); k++; }v2.addElement(new Integer(erg)); j++; }

ret.addElement(v2); i++; }return ret; }}

Motivation

System determines the principal typing(s)

mul: Matrix → Matrix &Matrix→ Vector<Vector<Integer>>& . . .&Vector<? extends Vector<? extends Integer>>

→ Vector<? super Vector<Integer>>

Motivation

Purpose: Typless

class Matrix extends Vector<Vector<Integer>> {mul(m) {

ret = new Matrix();

i = 0;

while(i <size()) {v1 = this.elementAt(i);

v2 = new Vector<Integer>();

j = 0;

while(j < v1.size()) {erg = 0;

k = 0;

while(k < v1.size()) {erg = erg + v1.elementAt(k)

* m.elementAt(k).elementAt(j); k++; }v2.addElement(new Integer(erg)); j++; }

ret.addElement(v2); i++; }return ret; }}

Inheritance hierarchy

extends/implements relation: ≤ (declared by the extends resp.implements declarations

Example: Stack<x>≤ Vector<x>(declared by class Stack<x> extends Vector<x>)

subtyping relation: ≤∗ (ordering of the Java 5.0 type terms)

Example:Stack<Vector<Integer>>≤∗ Vector<Vector<Integer>>

Inheritance hierarchy cont.

Definition: Finite closure FC( ≤ )

I reflexive and transitive closure of relationships in the subtypingordering, where in the left hand sides all arguments are typevariables.

Example: Matrix<x>≤∗ Vector<Vector<x>>(declared by class Matrix<x> extends Vector<Vector<x>>)

myLi<b, a>≤∗ List<a>(declared by class myLi<b,a> extends List<a>)

myLi<Integer, a>≤∗ List<a> is not an element of the finite closure.

LemmaThe finite closure is a finite subset of the subtyping relation ≤∗ .

Wildcards

Subtyping relation: Integer≤∗ NumberStack<a>≤∗ Vector<a>

It holds Stack<Integer>≤∗ Vector<Integer>

but Stack<Integer> 6≤∗ Vector<Number>

In the arguments no subtyping is allowed (soundness condition for theJava 5.0 type system)

Introduction of wildcards

I Stack<Integer>≤∗ Vector<? extends Number>? extends Number: all subtypes of Number are allowed

I Stack<Number>≤∗ Vector<? super Integer>? super Intger: all supertypes of Integer are allowed

Wildcards

Subtyping relation: Integer≤∗ NumberStack<a>≤∗ Vector<a>

It holds Stack<Integer>≤∗ Vector<Integer>

but Stack<Integer> 6≤∗ Vector<Number>

In the arguments no subtyping is allowed (soundness condition for theJava 5.0 type system)

Introduction of wildcards

I Stack<Integer>≤∗ Vector<? extends Number>? extends Number: all subtypes of Number are allowed

I Stack<Number>≤∗ Vector<? super Integer>? super Intger: all supertypes of Integer are allowed

Abbreviation for wildcard–types

Instead of A<? extends B> we write

and instead of C<? super D> we write

C<?D>.

Type Unification problemRelated workThe algorithm

Type Unification problem

For two type terms θ1 and θ2 a substitution σ is demanded suchthat:

σ( θ1 )≤∗ σ( θ2 ).

TEL [Smolka 1989]

I Type system without any restrictions

I Type unification algorithm is incomplete

I Open problem mentioned: infinte chains in the type term orderingFor List(a) ≤ myLi(a,b) holds:

List(a) ≤ myLi(a,List(a)) ≤ myLi(a,myLi(a,List(a))) ≤ . . .

For nat≤ int holds

{ nat l a, int l a } ⇒ a 7→ nat⇒ { int l nat } ⇒ fail

But there is a unifier a 7→ int.

The algorithm is incomplete even for types without infinite chains

TEL [Smolka 1989]

[Hill, Topor 1992]

I subtype relationships only of type constructors with the same arity

I most general type unifier (mgtu) defined as an upper bound ofdifferent principal type unifiers

For nat≤ int, neg≤ int holdsThe mgtu of { nat l a, neg l a } is { a 7→ int }

Extension: int≤ index and int≤ expr: nat

exprindex

There are three unifiers a 7→ int, a 7→ index, and a 7→ expr, but noneof them is a mgtu.

In general there is no mgtu in the sense of [Hill, Topor 1992].

[Hill, Topor 1992]

exprindex

[Hill, Topor 1992]

exprindex

[Hill, Topor 1992]

exprindex

PROTOS-L [Beierle 1995]

I no subtype relationship between polymorphic type constructorsI type unification algorithm completeI unification problem indeed not unitary, but finitaryI the algorithm is also complete for the type system of [Hill, Topor

For nat≤ int, neg≤ int, int≤ index, int≤ expr and

{ nat l a, neg l a }

there are three general unifiers

{ a 7→ int }, { a 7→ index }, and { a 7→ expr }.

The algorithm do not work on subtype relationships where theconstructors have different arities.

Java type unification [Plumicke 2004, Unif’04, Cork]

I no wildcards

I no subtyping in the arguments of the type terms (soundnesscondition)

For myLi<b, a>≤ List<a> and { myLi<Integer, a> l List<Boolean> }the general unifier

{ a 7→ Boolean }

is determined. For

{ myLi<Integer, Integer> l List<Number> }

the algorithm fails, as indeed Integer≤ Number, but subtyping in thearguments is prohibited.

No infinite chains appears.

I no wildcards

{ a 7→ Boolean }

is determined.

I no wildcards

{ a 7→ Boolean }

is determined. For

I no wildcards

{ a 7→ Boolean }

is determined. For

No infinite chains appears.Martin Plumicke Java Type Unification with Wildcards

Base of Hindley/Milner approach:(Type) unification algorithm [Martelli, Montanari 1982]

(reduce)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′1, . . . , θ′n> }

Eq ∪ { θ1.= θ′1, . . . , θn

.= θ′n }

(erase)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } a ∈ TV

(subst)Eq ∪ { a

.= θ }

Eq[a 7→ θ] ∪ { a.= θ } a occurs in Eq but not in θ

Type unification algorithm for Java 5.0 type terms withoutwildcards [Plumicke 2004, Unif’04, Cork]

(adapt)Eq ∪ {D<θ1, . . . , θn> l D′<θ′1, . . . , θ′m> }Eq ∪ {D′<θ

′1, . . . , θ

′m>[ai 7→ θi | 16 i 6n] l D′<θ′1, . . . , θ′m> }

where there are θ′1, . . . , θ

′m with

I (D<a1, . . . , an>≤∗ D′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(reduce1)Eq ∪ {C<θ1, . . . , θn> l D<θ′1, . . . , θ′n> }Eq ∪ { θπ( 1 )

.= θ′1, . . . , θπ( n )

.= θ′n }

I C<a1, . . . , an>≤∗ D<aπ( 1 ), . . . , aπ( n )>

I { a1, . . . , an } ⊆ TV

I π is a permutation

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′1, . . . , θ′n> }

Eq ∪ { θ1.= θ′1, . . . , θn

.= θ′n }

(erase)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } a ∈ TV

(subst)Eq ∪ { a

.= θ }

Eq[a 7→ θ] ∪ { a.= θ }

I a occurs in Eqbut not in θ

′1, . . . , θ

′m>[ai 7→ θi | 16 i 6n] l D′<θ′1, . . . , θ′m> }

′m with

I (D<a1, . . . , an>≤∗ D′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

.= θ′1, . . . , θπ( n )

.= θ′n }

I C<a1, . . . , an>≤∗ D<aπ( 1 ), . . . , aπ( n )>

I { a1, . . . , an } ⊆ TV

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′1, . . . , θ′n> }

Eq ∪ { θ1.= θ′1, . . . , θn

.= θ′n }

(erase)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } a ∈ TV

(subst)Eq ∪ { a

.= θ }

Eq[a 7→ θ] ∪ { a.= θ }

′1, . . . , θ

′m>[ai 7→ θi | 16 i 6n] l D′<θ′1, . . . , θ′m> }

′m with

I (D<a1, . . . , an>≤∗ D′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

.= θ′1, . . . , θπ( n )

.= θ′n }

I C<a1, . . . , an>≤∗ D<aπ( 1 ), . . . , aπ( n )>

I { a1, . . . , an } ⊆ TV

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′1, . . . , θ′n> }

Eq ∪ { θ1.= θ′1, . . . , θn

.= θ′n }

(erase)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } a ∈ TV

(subst)Eq ∪ { a

.= θ }

Eq[a 7→ θ] ∪ { a.= θ }

Type unification rules

(redUp)Eq ∪ { θ l ?θ′ }Eq ∪ { θ l θ′ } (redUpLow)

Eq ∪ { ?θ l ?θ′ }Eq ∪ { θ l θ′ } (redLow)

Eq ∪ { ?θ l θ′ }Eq ∪ { θ l θ′ }

Wildcards in outermost position

(red1)Eq ∪ {C<θ1, . . . , θn> l D<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

n }Reduce rule for outermost

type constructorwhere– C<a1, . . . , an>≤∗ D<aπ( 1 ), . . . , aπ( n )>

– { a1, . . . , an } ⊆ BTV

– π is a permutation

(redExt)Eq ∪ {X<θ1, . . . , θn>l? ?Y <θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

n }Reduce rule for

extends wildcardswhere– ?Y <aπ( 1 ), . . . , aπ( n )> ∈

grArg(X<a1, . . . , an> )– { a1, . . . , an } ⊆ BTV

Eq ∪ { ?θ l θ′ }Eq ∪ { θ l θ′ }

(red1)Eq ∪ {C<θ1, . . . , θn> l D<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

– { a1, . . . , an } ⊆ BTV

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

n }Reduce rule for

Eq ∪ { ?θ l θ′ }Eq ∪ { θ l θ′ }

(red1)Eq ∪ {C<θ1, . . . , θn> l D<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

– { a1, . . . , an } ⊆ BTV

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ) l? θ′1, . . . , θπ( n ) l? θ′

n }Reduce rule for

– π is a permutationMartin Plumicke Java Type Unification with Wildcards

(redSup)Eq ∪ {X<θ1, . . . , θn>l?

?Y <θ′1, . . . , θ′

n> }Eq ∪ { θ′

1 l? θπ( 1 ), . . . , θ′n l? θπ( n ) }

Reduce rule forsuper wildcards

– ?Y <aπ( 1 ), . . . , aπ( n )> ∈grArg(X<a1, . . . , an> )

– { a1, . . . , an } ⊆ BTV

(redEq)Eq ∪ {X<θ1, . . . , θn>l? X<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ).= θ′

1, . . . , θπ( n ).= θ′

n }Reduce rule for

equal type constructors

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′

1, . . . , θ′n> }

Eq ∪ { θ1.= θ′

1, . . . , θn.= θ′

n }Original reduce rule

(redSup)Eq ∪ {X<θ1, . . . , θn>l?

?Y <θ′1, . . . , θ′

n> }Eq ∪ { θ′

1 l? θπ( 1 ), . . . , θ′n l? θπ( n ) }

– { a1, . . . , an } ⊆ BTV

(redEq)Eq ∪ {X<θ1, . . . , θn>l? X<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ).= θ′

1, . . . , θπ( n ).= θ′

n }Reduce rule for

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′

1, . . . , θ′n> }

Eq ∪ { θ1.= θ′

1, . . . , θn.= θ′

(redSup)Eq ∪ {X<θ1, . . . , θn>l?

?Y <θ′1, . . . , θ′

n> }Eq ∪ { θ′

1 l? θπ( 1 ), . . . , θ′n l? θπ( n ) }

– { a1, . . . , an } ⊆ BTV

(redEq)Eq ∪ {X<θ1, . . . , θn>l? X<θ′

1, . . . , θ′n> }

Eq ∪ { θπ( 1 ).= θ′

1, . . . , θπ( n ).= θ′

n }Reduce rule for

(reduce2)Eq ∪ {C<θ1, . . . , θn>

.= C<θ′

1, . . . , θ′n> }

Eq ∪ { θ1.= θ′

1, . . . , θn.= θ′

(adapt)Eq ∪ {D<θ1, . . . , θn> l D ′<θ′

1, . . . , θ′m> }

Eq ∪ {D ′<θ′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l D ′<θ′

1, . . . , θ′m> }

′m with outermost adapt rule

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(adaptExt)Eq ∪ {D<θ1, . . . , θn>l? ?D

′<θ′1, . . . , θ′

m> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

m> }where there are θ

′1, . . . , θ

′m with adapt rule: extends wildcard

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(adaptSup)Eq ∪ {D ′<θ′

1, . . . , θ′m>l?

?D<θ1, . . . , θn> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

′1, . . . , θ

′m with adapt rule: super wildcard

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(adapt)Eq ∪ {D<θ1, . . . , θn> l D ′<θ′

1, . . . , θ′m> }

Eq ∪ {D ′<θ′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l D ′<θ′

1, . . . , θ′m> }

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

′<θ′1, . . . , θ′

m> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

′1, . . . , θ

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

1, . . . , θ′m>l?

?D<θ1, . . . , θn> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

′1, . . . , θ

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(adapt)Eq ∪ {D<θ1, . . . , θn> l D ′<θ′

1, . . . , θ′m> }

Eq ∪ {D ′<θ′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l D ′<θ′

1, . . . , θ′m> }

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

′<θ′1, . . . , θ′

m> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

′1, . . . , θ

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

1, . . . , θ′m>l?

?D<θ1, . . . , θn> }Eq ∪ {D ′<θ

′1, . . . , θ

′m>[ai 7→ CC( θi ) | 16 i 6n] l? ?D

′<θ′1, . . . , θ′

′1, . . . , θ

I (D<a1, . . . , an>≤∗ D ′<θ′1, . . . , θ

′m>) ∈ FC( ≤ )

(erase1)Eq ∪ { θ l θ′ }Eq

θ≤∗ θ′

(erase2)Eq ∪ { θ l? θ′ }Eq

θ′ ∈ grArg( θ )

(erase3)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } θ 6∈ BTV , a ∈ BTV

(subst)Eq′ ∪ { a

.= θ }

Eq′[a 7→ θ] ∪ { a.= θ } a occurs in Eq′ but not in θ

(erase1)Eq ∪ { θ l θ′ }Eq

θ≤∗ θ′

(erase2)Eq ∪ { θ l? θ′ }Eq

θ′ ∈ grArg( θ )

(erase3)Eq ∪ { θ

.= θ′ }

Eqθ = θ′

(swap)Eq ∪ { θ

.= a }

Eq ∪ { a.= θ } θ 6∈ BTV , a ∈ BTV

(subst)Eq′ ∪ { a

.= θ }

Eq′[a 7→ θ] ∪ { a.= θ } a occurs in Eq′ but not in θ

Type unification algorithm with wildcards

1. Repeated application of the reduce rules, the erase rules, the swaprule, and the adapt rules.

2. For each pair a l θ and a l? θ for all subtypes θ of θ, constructed bypattern–matching with elements from FC( ≤∗ ,BTV ), pairs a

are built.

3. For each pair θ l a and θ l? a for all supertypes θ′ of θ, constructedby pattern–matching with elements from FC( ≤∗ ,BTV ), pairsa

.= θ′ are built.

4. The cartesian product of the sets from step 2 and 3 is built.

5. Application of the subst rule

6. For all changed sets of type terms start again with step 1.

7. Summerize all results.

are built.

.= θ′ are built.

are built.

.= θ′ are built.

are built.

.= θ′ are built.

are built.

.= θ′ are built.

are built.

.= θ′ are built.

are built.

.= θ′ are built.

Example

Subtyping relation:Integer≤∗ NumberStack<a>≤∗ Vector<a>≤∗ AbstractList<a>≤∗ List<a>

Application of the algorithm:{ (Stack<a> l Vector<?Number>), (AbstractList<Integer> l List<a>) }

(red1)=⇒ { al? ?Number, Integerl? a }2./3./4.=⇒ { { a .

= ?Number, a.= Integer }, { a .

= ?Number, a.= ?Number },

{ a .= ?Number, a

.= ?Integer }, { a

.= ?Number, a

.= ?Integer },

{ a .= Number, a

.= Integer }, { a .

= Number, a.= ?Number },

{ a .= Number, a

.= ?Integer }, { a

.= Number, a

.= ?Integer },

{ a .= ?Integer, a

.= Integer }, { a .

= ?Integer, a.= ?Number },

{ a .= ?Integer, a

.= ?Integer }, { a

.= ?Integer, a

.= ?Integer },

{ a .= Integer, a

.= Integer }, { a .

= Integer, a.= ?Number },

{ a .= Integer, a

.= ?Integer }, { a

.= Integer, a

.= ?Integer } }

Example

{ a .= ?Number, a

.= ?Integer }, { a

.= ?Number, a

.= ?Integer },

{ a .= Number, a

.= Integer }, { a .

{ a .= Number, a

.= ?Integer }, { a

.= Number, a

.= ?Integer },

{ a .= ?Integer, a

.= Integer }, { a .

{ a .= ?Integer, a

.= ?Integer }, { a

.= ?Integer, a

.= ?Integer },

{ a .= Integer, a

.= Integer }, { a .

{ a .= Integer, a

.= ?Integer }, { a

.= Integer, a

.= ?Integer } }

Example

{ a .= ?Number, a

.= ?Integer }, { a

.= ?Number, a

.= ?Integer },

{ a .= Number, a

.= Integer }, { a .

{ a .= Number, a

.= ?Integer }, { a

.= Number, a

.= ?Integer },

{ a .= ?Integer, a

.= Integer }, { a .

{ a .= ?Integer, a

.= ?Integer }, { a

.= ?Integer, a

.= ?Integer },

{ a .= Integer, a

.= Integer }, { a .

{ a .= Integer, a

.= ?Integer }, { a

.= Integer, a

.= ?Integer } }

Example cont.

5.step (subst)=⇒

{{ Integer .= ?Number, a

.= Integer }, { ?Number

.= ?Number, a

.= ?Number },

{ ?Integer.= ?Number, a

.= ?Integer }, { ?Integer

.= ?Number, a

.= ?Integer },

{ Integer .= Number, a

.= Number, a

.= ?Number },

{ ?Integer.= Number, a

.= Number, a

.= ?Integer },

{ Integer .= ?Integer, a

.= ?Integer, a

.= ?Number },

{ ?Integer.= ?Integer, a

.= ?Integer, a

.= ?Integer },

{ Integer .= Integer, a

.= Integer, a

.= ?Number },

{ ?Integer.= Integer, a

.= ?Integer }{ ?Integer

.= Integer, a

.= ?Integer } }

(erase3)=⇒ {{ a 7→ ?Number }, { a 7→ ?Integer }, { a 7→ Integer } }

Example: Infinite chains

Subtyping relation: myLi<b, a>≤ List<a>

There is an infinite chain:

. . . ≤∗ myLi<?myLi<?List<a>, a>, a>≤∗ myLi<?List<a>, a>≤∗ List<a>

Application of the algorithm:{ List<x> l List<?List<Integer>> }

(red1)⇒ { xl? ?List<Integer> }3.step⇒ {{ x 7→ List<Integer> }, { x 7→ ?List<Integer> },

{ x 7→ myLi<b, Integer> }, { x 7→ ?myLi<b, Integer> } }.Although, there are infinite subtypes of x only a finite number ofgeneral unifiers is determined.All other unifiers are instances of these.

{ x 7→ myLi<b, Integer> }, { x 7→ ?myLi<b, Integer> } }.

Although, there are infinite subtypes of x only a finite number ofgeneral unifiers is determined.All other unifiers are instances of these.

Results

Theorem (Soundness and Completeness)

The type unification algorithm is sound and complete.

Corollary (Finitary)

The type unification of Java 5.0 type terms with wildcards is finitary.

Corollary (Termination)

The type unification algorithm terminates.

The finitary corollary means that the open problem of[Smolka 1989] is solved by our type unification algorithm.

Conclusion and future work

ConclusionI Java 5.0 type unification problem corresponds to the type

unification problem of logical programming languages

I Type unification algorithm for subtype relationships

I Subtype relationships of different arities are allowed

Future workI Integration of the extended type unification algorithm into the

Java 5.0 type inference algorithm (nearly done)

I Extension of a prolog implementation by the type unificationalgorithm.

Conclusion and future work

ConclusionI Java 5.0 type unification problem corresponds to the type

unification problem of logical programming languages

I Type unification algorithm for subtype relationships

I Subtype relationships of different arities are allowed

Future workI Integration of the extended type unification algorithm into the

Java 5.0 type inference algorithm (nearly done)

I Extension of a prolog implementation by the type unificationalgorithm.

java type unification with wildcardspl/talks/wlp2007.pdf · 2011. 9. 29. · introduction subtyping...

Documents