Java type inference with wildcards - Leiden...

IntroductionThe Algorithm

Conclusion

Java type inference with wildcards

Martin Plumicke

University of Cooperative EducationStuttgart/Horb

7. November 2006

Martin Plumicke Java type inference with wildcards

Conclusion

Overview

IntroductionProblemRelated work

The AlgorithmType unificationType-inference-algorithmTool demonstrationPrinciple type

Conclusion

ProblemRelated work

Problem

Extensions of the Java 5.0 type–systemI parametrized 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

Conclusion

ProblemRelated work

Problem

variables

Conclusion

ProblemRelated work

Problem

variables

Conclusion

ProblemRelated work

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

Conclusion

ProblemRelated work

Alternative Typing

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

Matrix/Vector<Vector<Integer>> 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;

Conclusion

ProblemRelated work

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;

Conclusion

ProblemRelated work

System determines the principle typing(s)

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

→ Vector<? super Vector<Integer>>

Conclusion

ProblemRelated work

Related work

over type expressions)

recursive typeF−bounded polymorphismus

(Cartesian product algorithm

(Data polymorpic Cartesian product algorithm in Java)

type system

S−unification)

[Plevyak, Chien 94]

(Precise concrete TI in OO data polymorphism function polymorphism no principal type)

(inclusion constraints)

[Hindley/Milner et. al.]

[Aiken, Wimmer 93]

[Eifrig, Smith, Trifonov 95a/b][Agesen 95/96]

no data polymorphism) [Agesen, Palsberg, Schwartzbach 93]

[Palsberg, Schwartzbach 91]

(TI in OO−Languages)

(Inheritance)

[Wang, Smith 01]

(Type parameter inference, Generic Libraries

(Type parameter inference, Generic Libraries Extension of [Palsberg, Schwartzbach 94] to parametrized types)

[Fuhrer, Tip Kiezun, Dolby, Keller 05]

[Donovan,Kiezun, Tschantz, Ernst 04]

(copying classes)

diiferentiation of declaration and allocation side

[Oxhoj, Palsberg, Schwartzbach 92]

Conclusion

ProblemRelated work

Related work

recursive typeF−bounded polymorphismus

type system

S−unification)

[Plevyak, Chien 94]

[Aiken, Wimmer 93]

[Eifrig, Smith, Trifonov 95a/b][Agesen 95/96]

no data polymorphism) [Agesen, Palsberg, Schwartzbach 93]

(Inheritance)

[Wang, Smith 01]

(copying classes)

precise typesno principle type

Extension of [Palsberg, Schwartzbach 94] to parametrized types)

Conclusion

ProblemRelated work

Related work

recursive type

F−bounded polymorphismus

type system

S−unification)

precise types

(Type parameter inference, Generic Libraries Extension of [Palsberg, Schwartzbach 94] to parametrized types)

(copying classes)

[Agesen, Palsberg, Schwartzbach 93]

(Inheritance)

[Wang, Smith 01]

[Aiken, Wimmer 93]

[Eifrig, Smith, Trifonov 95a/b]

[Plevyak, Chien 94]

no principle type

[Agesen 95/96]

no data polymorphism)

λ− Terms

Conclusion

ProblemRelated work

Our approach

[Hindley/Milner et al]

– function type constructor → (no higher–order functions)

+ function template (ty1 × . . . tyn) → ty0

(first–order functions)

+ data and function polymorphism (overloading)

Conclusion

ProblemRelated work

Our approach

Conclusion

ProblemRelated work

Our approach

Conclusion

ProblemRelated work

Abbreviation for wildcard–types

Instead of A<? extends B> we write

and instead of C<? super D> we write

C<?D>.

Conclusion

Type unificationType-inference-algorithmTool demonstrationPrinciple type

The algorithm

Type unification

Subtyping relation for type terms: ≤∗

Type Unification problem:

For two type terms θ1 and θ2 a substitution σ is demandedsuch that:

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

Conclusion

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 θ

Conclusion

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 θ

Conclusion

′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.= θ }

Conclusion

′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.= θ }

Conclusion

Type unification algorithm with wildcards

(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 outermosttype symbol

where– 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 forextends wildcards

where– ?Y <aπ( 1 ), . . . , aπ( n )> ∈ gr(X<a1, . . . , an> )– { a1, . . . , an } ⊆ BTV

Conclusion

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

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

′n> }

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

′n }

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

′n> }

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

′n }

Conclusion

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

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

′n> }

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

′n }

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

′n> }

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

′n }

Conclusion

(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 )> ∈ gr(X<a1, . . . , an> )– { a1, . . . , an } ⊆ BTV

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

′n> }

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

.= θ′n }

Reduce rule forequal type symbols

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

.= C<θ′1, . . . , θ

′n> }

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

.= θ′n }

Original reduce rule

Conclusion

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

?Y <θ′1, . . . , θ′n> }

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

′n> }

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

.= θ′n }

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

.= C<θ′1, . . . , θ

′n> }

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

.= θ′n }

Conclusion

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

?Y <θ′1, . . . , θ′n> }

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

′n> }

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

.= θ′n }

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

.= C<θ′1, . . . , θ

′n> }

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

.= θ′n }

Conclusion

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

′m> }

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

′m>[ai 7→ θ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→ θi | 16 i 6n] l? ?D

′<θ′1, . . . , θ′m> }

′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→ θi | 16 i 6n] l? ?D

′<θ′1, . . . , θ′m> }

′m with adapt rule: super wildcard

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

′m>) ∈ FC( ≤ )

Conclusion

′m> }

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

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

′m> }

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

′m>) ∈ FC( ≤ )

′<θ′1, . . . , θ′m> }

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

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

′<θ′1, . . . , θ′m> }

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

′m>) ∈ FC( ≤ )

(adaptSup)Eq ∪ {D ′<θ′1, . . . , θ

′m>l?

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

′1, . . . , θ

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

′<θ′1, . . . , θ′m> }

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

′m>) ∈ FC( ≤ )

Conclusion

′m> }

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

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

′m> }

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

′m>) ∈ FC( ≤ )

′<θ′1, . . . , θ′m> }

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

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

′<θ′1, . . . , θ′m> }

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

′m>) ∈ FC( ≤ )

(adaptSup)Eq ∪ {D ′<θ′1, . . . , θ

′m>l?

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

′1, . . . , θ

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

′<θ′1, . . . , θ′m> }

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

′m>) ∈ FC( ≤ )

Conclusion

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

θ≤∗ θ′

(erase2)Eq ∪ { θl? θ

′ }Eq

θ′ ∈ gr( θ )

(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 θ

Conclusion

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

θ≤∗ θ′

(erase2)Eq ∪ { θl? θ

′ }Eq

θ′ ∈ gr( θ )

(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 θ

Conclusion

Example

Subtyping relation: Matrix<a>≤∗ Vector<Vector<a>>Vector<a>≤∗ AbstractList<a>≤∗ List<a>

Application of the algorithm:{ Matrix<b> l Vector<Vector<?AbstractList<Object>>>, a l b }

(adapt)=⇒ { Vector<Vector<b>> l Vector<Vector<?AbstractList<Object>>>,

a l b }(red1,redEq)

=⇒ { b .= ?AbstractList<Object>,

a l b }(subst)=⇒ { b .

= ?AbstractList<Object>,a l ?AbstractList<Object> }

(new sets)=⇒ {{ b .

= List<Object>, a.= AbstractList<Object> },

{ b .= List<Object>, a

.= ?AbstractList<Object> },

.= Vector<Object> },

.= ?Vector<Object> } }

Conclusion

Type–inference–algorithm

Type assumptions: For each absent type in the program atype-placeholder (fresh type variable) is assumed.

Run over the abstract syntax tree: During the run over abstract syntaxtree of the coresponding java class the types are calculatedgradually by type unification.

Multiplying the assumptions: If the result of a type unification containsmore than one result or if there is data polymorphism, the set oftype assumptions is multiplied.

Erase type assumptions: If the type unification fails, the correspondingset of type assumptions is erased.

New method type parameters: At the end remained type-placeholdersare replaced by new introduced method type parameters.

Intersection types: At the end each remained set of type assumptionsforms one element of the result’s intersection type.

Conclusion

Type–inference rules

(O, τ, τ ′) BExpr e1 : θ′, (O, τ, τ ′) BExpr e2 : θ[Assign]

(O, τ, τ ′) BExpr Assign( e1, e2 ) : θ′θ≤∗ θ′

(O, τ, τ ′) BExpr re : θ∀16 i 6n : (O, τ, τ ′) BExpr ei : θi ,

(θ′1 . . . θ′n, θ) = lub( θ, f , (θ1, . . . , θn) )

[Method-Call

](O, τ, τ ′) BExpr MethodCall( re, f ( e1, . . . , en ) ) : θ

(O, τ, τ ′) BExpr e : θ[Return]

(O, τ, τ ′) BStmt Return( e ) : θ

Conclusion

(θ′1 . . . θ′n, θ) = lub( θ, f , (θ1, . . . , θn) )

[Method-Call

Conclusion

(θ′1 . . . θ′n, θ) = lub( θ, f , (θ1, . . . , θn) )

[Method-Call

Conclusion

Example: Multiplication of matrices: Type assumptions

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

{ γ } ret = new Matrix();

int i = 0;

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

{κ } v2 = new Vector<Integer>();

int j = 0;

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

int k = 0;

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

* ({ψ }({φ } ({β } m).elementAt(k)).elementAt(j)); k++;}v2.addElement({χ } erg); j++; }

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

Conclusion

ret = new Matrix ()

{α } mul({β } m) {{ γ } ret = { Matrix } new Matrix();. . .return { γ } ret;

Unification: Matrix l γ

⇒γ = Matrixγ = Vector<Vector<Integer>>γ = Vector<?Vector<Integer>>γ = Vector<?Vector<?Integer>>γ = Vector<?Vector<

?Integer>>γ = Vector<?Vector<Integer>>

Conclusion

Type assumptions after the first unification

class Matrix extends Vector<Vector<Integer>> {{α, α, α, α, α, α } mul({β, β, β, β, β, β } m) {

{ Matrix, Vector<Vector<Integer>>, Vector<?Vector<Integer>>,Vector<?Vector<?Integer>>, Vector<?Vector<

?Integer>>,Vector<?Vector<Integer>> } ret = new Matrix();

int i = 0; while(i <size()) {{ ι, ι, ι, ι, ι, ι } v1 = this.elementAt(i);

{κ, κ, κ, κ, κ, κ } v2 = new Vector<Integer>();

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

int k = 0; while(k < v1.size()) {erg = erg +({ ξ, ξ, ξ, ξ, ξ, ξ }({ ι, ι, ι, ι, ι, ι } v1).elementAt(k))

* ({ψ,ψ, ψ, ψ, ψ, ψ }({φ, φ, φ, φ, φ, φ }({β, β, β, β, β, β } m).elementAt(k)).elementAt(j)); k++;}

v2.addElement({χ, χ, χ, χ, χ, χ } erg); j++; }ret.addElement({µ, µ, µ, µ, µ, µ } v2); i++; }

return ret; }}Martin Plumicke Java type inference with wildcards

Conclusion

v1 = this.elementAt(i);

{α } mul({β } m) {. . .{ ι } v1 = ({ Matrix } this).elementAt(i);. . .

Unification: Matrix l Vector<ι>

ι = Vector<Integer>ι = Vector<?Integer>ι = Vector<?Integer>

Conclusion

v2 = new Vector<Integer> ();

{α } mul({β } m) {. . .{κ } v2 = { Vector<Integer> } new Vector<Integer>();. . .

Unification: Vector<Integer> l κ

κ = Vector<Integer>κ = Vector<?Integer>κ = Vector<?Integer>

Conclusion

erg = erg + v1.elementAt(k)

* m.elementAt(k)).elementAt(j)); (I)

{α } mul({β } m) {. . .

{χ } erg = {χ } erg + ({ ξ }({ ι }v1).elementAt(k))* ({ψ }({φ } ({β } m).elementAt(k)).elementAt(j)); k++;}

. . .}

({β } m).elementAt(k): Unification: β l Vector<φ>β = Vector<φ>β = Matrix ⇒ φ = Vector<Integer> or

φ = ?Vector<Integer> orφ = ?Vector<?Integer> orφ = ?Vector<Integer>

Conclusion

* m.elementAt(k)).elementAt(j)); (II)

({φ }({β }m).elementAt(k)).elementAt(j):

Unification: φl Vector<ψ>

β = Vector<φ> ⇒ φ = Vector<ψ> orφ = ?Vector<ψ> orφ = Matrix

β = Matrix⇒ φ = Vector<Integer>⇒ OKφ = . . .

Conclusion

* m.elementAt(k)).elementAt(j)); (III)

({ ξ }({ ι }v1).elementAt(k))*({ψ }({φ }({β }m).elementAt(k)).elementAt(j)):β = Vector<φ> :

From * : (int, int) → int follows

Unification: ψ l Integer

φ = Vector<ψ> ⇒ ψ = Integer⇒ OK⇒ ψ = ?Integer⇒ OK

φ = ?Vector<ψ> ⇒ ψ = Integer⇒ OK⇒ ψ = ?Integer⇒ OK

φ = Matrix⇒ (ψ =)Vector<Integer> l Integer⇒ fail⇒ assumption is erased

Conclusion

* m.elementAt(k)).elementAt(j)); (IV)

{α } mul({β } m) {. . .

Result for β:

β = Vector<Vector<Integer>>β = Vector<Vector<?Integer>>β = Vector<?Vector<Integer>>β = Vector<?Vector<?Integer>>β = Matrix

Conclusion

* m.elementAt(k)).elementAt(j)); (V)

{χ } erg = {χ } erg + ({ ξ }({ ι }v1).elementAt(k))*({ψ }({φ }({β }m).elementAt(k)).elementAt(j)):

From +, * : (int, int) → intwith

ξ = Integer l Integerξ = ?Integer l Integer

andψ = Integer l Integerψ = ?Integer l Integer

followsχ = Integer

Conclusion

v2.addElement(erg);

{α } mul({β } m) {. . .{κ } v2 = new Vector<Integer>();. . .v2.addElement({χ } erg);. . .

χ = Integer, κ = Vector<Integer>⇒ Integer l Integer⇒ OK

χ = Integer, κ = Vector<?Integer>⇒ Integer l ?Integer⇒ fail⇒ assumption is erased

χ = Integer, κ = Vector<?Integer>⇒ Integer l ?Integer⇒ OK

Conclusion

ret.addElement(v2); (I)

{ γ } ret = new Matrix(); . . . ; ret.addElement({κ } v2);

κ = Vector<Integer>, γ = Matrix⇒ Vector<Integer> l Vector<Integer>⇒ OK

κ = Vector<Integer>, γ = Vector<Vector<Integer>>⇒ Vector<Integer> l Vector<Integer>⇒ OK

κ = Vector<Integer>, γ = Vector<?Vector<Integer>>⇒ Vector<Integer> l ?Vector<Integer>⇒ fail

κ = Vector<Integer>, γ = Vector<?Vector<?Integer>>⇒ Vector<Integer> l ?Vector<?Integer>⇒ fail

κ = Vector<Integer>, γ = Vector<?Vector<?Integer>>

⇒ Vector<Integer> l ?Vector<?Integer>⇒ fail

κ = Vector<Integer>, γ = Vector<?Vector<Integer>>⇒ Vector<Integer> l ?Vector<Integer>⇒ OK

Conclusion

ret.addElement(v2); (II)

{ γ } ret = new Matrix(); . . . ; ret.addElement({κ } v2);

With κ = Vector<?Integer> for all assumptions of γ type unificationfails.

Result:γ = Matrixγ = Vector<Vector<Integer>>γ = Vector<?Vector<Integer>>

Conclusion

return ret;

{α } mul({β } m) {. . .return { γ } ret;

}Unification: γ l α forγ = Matrixγ = Vector<Vector<Integer>>γ = Vector<?Vector<Integer>>

Result: α = Matrixα = Vector<Vector<Integer>>α = Vector<?Vector<Integer>>α = Vector<?Vector<Integer>>α = Vector<?Vector<?Integer>>α = Vector<?Vector<

?Integer>>Martin Plumicke Java type inference with wildcards

Conclusion

Result:

mul: &α,β(α→β),

α≤∗ Vector<?Vector<?Integer>>,Matrix≤∗ β

Conclusion

Principal type

Definition [Damas, Milner 1982]:

“A type-scheme for a declaration is a principal type-scheme, if any othertype-scheme for the declaration is a generic instance of it.”

Generalization to the Java 5.0 type system

“An intersection type-scheme for a declaration is a principal type-scheme,if any other type-scheme for the declaration is a generic instance of oneelement of the intersection type-scheme.”

Conclusion

Principal type

Definition [Damas, Milner 1982]:

“A type-scheme for a declaration is a principal type-scheme, if any othertype-scheme for the declaration is a generic instance of it.”

Generalization to the Java 5.0 type system

“An intersection type-scheme for a declaration is a principal type-scheme,if any other type-scheme for the declaration is a generic instance of oneelement of the intersection type-scheme.”

Conclusion

Principal type

DefinitionAn intersection type of a method m in a class C

m : (θ1,1 × . . .× θ1,n → θ1)& . . .&(θm,1 × . . .× θm,n,→ θm)

is called principal if for any correct type annotated method declaration

rty m(ty1 a1 , . . . , tyn an) { . . . }

there is an element (θi ,1 × . . .× θi ,n,→ θi ) of the intersection type andthere is a substitution σ, such that

σ( θi )≤∗ rty , ty1 ≤∗ σ( θi ,1 ), . . . , tyn ≤∗ σ( θi ,n )Martin Plumicke Java type inference with wildcards

Conclusion

Reduced principal type:

The inferred type of the example

where α≤∗ Vector<?Vector<?Integer>> and Matrix≤∗ β.

is a principle type.

But there is also a reduced principle type:

mul: Vector<?Vector<?Integer>>→ Matrix

Conclusion

Reduced principal type:

The inferred type of the example

where α≤∗ Vector<?Vector<?Integer>> and Matrix≤∗ β.

is a principle type.

But there is also a reduced principle type:

mul: Vector<?Vector<?Integer>>→ Matrix

Conclusion

Principle type property

TheoremThe type inference algorithm calculates a principle type.

Conclusion

Tool demonstration

I Matrix–Example

I Overloading–Example

Conclusion

Conclusion and future work

ConclusionI Type-inference-algorithm for Java 5.0

I Type unification

I Principle type property

Future workI Reduce the number of calculated typings.

I Handling of interesection types (adaption of byte-code generation)

Conclusion

Conclusion and future work

ConclusionI Type-inference-algorithm for Java 5.0

I Type unification

I Principle type property

Future workI Reduce the number of calculated typings.

I Handling of interesection types (adaption of byte-code generation)

Java type inference with wildcards - Leiden...

Documents

Decodificador para 4 Servos v2 - TINET - Tarragona …usuaris.tinet.cat/fmco/download/4servo_manual_v2.pdfservos disponen de tres cables dos para alimentación Vcc y Gnd y otro cable

CONTROL DE ACCESORIOS POR DCCusuaris.tinet.cat/fmco/download/Control_accesorios_DCC...un modo especial de programación en el cual espera que desde la central se mueva un accesorio

Model-Driven Engineeringliacs.leidenuniv.nl/~bonsanguemm/fmco/2003/jezequel.pdf · 1 Model-Driven Engineering: Core Principles and Challenges * Prof. Jean-Marc Jézéquel (Univ.Rennes

XWL – Mandos inalámbricosusuaris.tinet.cat/fmco/download/XWL_manual.pdf · alimenta desde una pila de 9V (6LR61). ... para obtener un correcto funcionamiento del sistema y evitar

Decodificador Universal para Semáforos v1usuaris.tinet.cat/fmco/download/UniSemaf_manual.pdfcuenta que se ha de conservar el valor de la última posición, por lo que quizás primero

UniSemaf-648 v1usuaris.tinet.cat/fmco/download/UniSemaf648_manual.pdf · 4.- Ejemplos de conexión 4.1. – 2 Semáforo de 2 luces Se pueden controlar dos semáforos de 2 posiciones

Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components Marjan Sirjani Tehran University, IPM FMCO’06 Amsterdam

ГОСТ 24997-2004 - Калибры для ... · FOOT 8724—2002 (ØCO 261—98) OcuoeHbre gaauM03aMeHqeuocmu Peab6a MempuqecxaR AuaMempb' u tuaeu FOCT 9150—2002 fMCO 68-1—98)

Guía práctica de iniciación aplicada al Modelismo Ferroviariousuaris.tinet.cat/fmco/download/Lenguaje_de_programacion_Arduino… · 2 Esta pequeña guía práctica surge como un

Séries Temporais Financeiras Aula 6 Propriedades da Função ...chang/home/mae325/MAE0518-Modelage… · chamado ruído bmnco fmco. Contudo, usaremos simplesmente a nomenclatura

TT-F9152 Decoder para plataforma giratoriausuaris.tinet.cat/fmco/download/TT-F9152_manual.pdf · Los restantes optoacopladores se encargan de las señales DCC o Motorola presentes

XbusTCO 2 manual ESP - TINET - Tarragona Internet | La ...usuaris.tinet.cat/fmco/download/XbusTCO_manual.pdf · interruptor, cuando se detecta un cambio se envía a la central la

The refractive development of the eye of the American ... · The refractive development of the eye of the American kestrel (FMco sparverius): ... form deprivation caused a significant

Testing Object Oriented Software - Leiden Universityliacs.leidenuniv.nl/~bonsanguemm/Toos/TOOS_2017_01.pdfDiscover the world at Leiden University Course programme Introduction to the

fmcO objetivo do transplante de células tronco de doador compatível e homozigoto para a mutação CCR5Ä32 visou à cura de duas doenças graves no paciente: a leucemia e a Aids

PAN-Sound (v1.0) – Manual de Instruccionesusuaris.tinet.cat/fmco/download/PANsound_manual.pdfcon movimiento lento de las barreras, encendido/apagado lento de las luces y sonido de

FMCO 2005 / UpSTAIRS with Sequence Diagrams Ragnhild Kobro Runde UpSTAIRS with Sequence Diagrams Øystein Haugen, Ragnhild Kobro Runde, Ketil Stølen University

BoosteR-CDE - usuaris.tinet.catusuaris.tinet.cat/fmco/download/BoosteR-CDE_manual.pdf · fmco 5.- RailCom RailCom es el nombre de la tecnología de comunicación bi-direccional desarrollada

A Facilities Management Company (FMCO) An Executive Presentation for UAE

DCC2DMX v2B - usuaris.tinet.orgusuaris.tinet.org/fmco/download/DCC2DMX_v2_manual.pdfEl DCC2DMX es un decodificador DCC que posee una salida DMX para controlar equipos de iluminación,