1. On Subtyping, Wildcards, and Existential Types
Nicholas Cameron
Sophia Drossopoulou
Victoria University of Wellington
Imperial College London

2. Polymorphism An expression may have many types
An expression with a given type may be treated as if it had a different type

3. Polymorphism Inclusion polymorphism – subtyping
Parametric polymorphism – generics
Ad-hoc polymorphism – coercions and overloading

4. Subclassing
Reuse code and encapsulate implementation class Dog {...} class Poodle extends Dog {...} class Husky extends Dog {...}

5. Subclassing Gives rise to subtyping Poodle <: Dog Husky <: Dog
Which gives inclusion polymorphism Dog d = new Husky(); d = new Poodle();

6. Subclassing
Inclusion polymorphism can be represented using existential types
Igarashi, Viroli; TOPLAS '06
Bruce, Petersen, Fiech; ECOOP '97
Saito, Igarashi; SAC '09
Abadi, Cardelli, Vishwanathan; POPL '96
....
ƎX<:Dog.X
The existential quantification makes explicit the partial knowledge about values with such types
vs exact

7. Generics Parametric polymorphism in Java List<Dog> Invariant
List<Poodle> </: List<Dog>

8. Wildcards Allow for variant generic types
List<? extends Poodle> <: List<? extends Dog>

9. Wildcards Can be represented using existential types
Torgersen et al; SAC '04
Torgersen, Ernst, Plesner Hansen; FOOL '05
Cameron, Drossopoulou, Ernst; ECOOP '08
Cameron, Ernst, Drossopoulou; FTfJP '07
ƎX<:Dog.List<X>
The existential quantification makes explicit the partial knowledge about values with such types

10. Is there a connection? Ǝ Ǝ Ǝ Ǝ Ǝ Ǝ Ǝ

11. Is there a connection? Two different uses for existential types
Are they the same type of types?
Can they be combined cleanly or are they orthogonal?
How do we combine the two uses?

12. A Story FJ - ƎFJ C ƎX<:C.X FGJ - ƎFGJ C<D>
ƎX<:C<D>.X
Wildcards - ƎWFJ
C<? extends D>
ƎX<:(ƎY<:D.C<Y>). X

13. Types
Break the automatic connection from subclassing to subtyping to polymorphism and classes to types
Give a clearer and more precise account of typing
Class names give brands, which cannot be used as types by the programmer
Malayeri, Aldrich; ECOOP '08
Brands correspond to class names, what is declared, not how they can be used as types
E.g., Dog, Poodle
Subclassing relates brands

14. Types Existential types may be bounded by brands
All polymorphism is explicit and given by the existential types
ƎX<:Dog.X
Existential types are the bridge from subclassing to polymorphism
Subclassing between brands: Poodle <: Dog
Subtyping between types: ƎX<:Poodle.X <: ƎX<:Dog.X

15. Types
A brand can be used to make a type, it is not a type by itself, in particular the subtyping properties are not specified
We could also have exact types, eg
@Dog which is the type of Dog without subclassing
@Poodle

16. Types
BUT we treat brands as types and sub-branding as subtyping

17. ƎFJ
Model for Java 1.4
Uses existential types to make polymorphism explicit
Corresponds to FJ
N ::= C
P ::= N | X
T ::= ƎX<:P.X
Brands
Parameters
Types

18. ƎFGJ

19. ƎFGJ Model for Java with generics (but not wildcards)
Simply adds type parameters to ƎFJ
eg List<Dog> in Java
ƎX<:List<Dog>.X in ƎFGJ
Note: List<Dog> is a brand, types are parameterised by brands, not types
N ::= C<P>
P ::= N | X
T ::= ƎX<:P.X
Brands
Parameters
Types

20. Wildcards This very nearly gives us wildcards for free!
That is, wildcards emerge naturally from the combination of a calculus which makes polymorphism explicit and type parameters
Example:
List<? extends Dog>
ƎX<:(ƎY<:Dog.List<Y>).X
This is how we can combine existential types

21. Wildcards We generalise the syntax very slightly
Bound type variables may be used as bounds and parameters
Allow quantification of brands as well as types
ƎX<:(ƎY<:Dog.List<Y>).X
And change the definition of well-formed types accordingly
The rest of the system just works!
Not orthogonal

22. Wildcards N ::= C<P> Brands P ::= ƎX<:P.N | X | X Parameters
T ::= ƎX<:P.X
Brands
Parameters
Types

23. Understanding Wildcards

24. Understanding Wildcards
Wildcards are difficult to understand
Confusion between the polymorphic behaviour of class types and the invariance of class names when used as type parameters
Polymorphic behaviour of type parameters is complex
We try to make the variance explicit

25. Understanding Wildcards
Type parameters are not types
Variance denoted by existential quantification `at the top'

26. Understanding Wildcards
Dog
List<Dog>
List<? extends Dog>
ƎX<:Dog.X
ƎX<:List<Dog>.X
ƎX<:(ƎY<:Dog.List<Y>).X

27. Thank you!
Questions?

28. Understanding Wildcards
class Box<X> { X get() {...} void set(X x) {...} }
Box<Dog> b = new Box<Dog>(); b.set(new Poodle()); Dog d = b.get();
Box<? extends Dog> b = new Box<Dog>(); b.set(null); Dog d = b.get()
Box<? super Dog> b = new Box<Dog>(); b.set(new Poodle()); Object d = b.get()

29. Understanding Wildcards
class Box<X> { ƎY<:X.Y get() {...} void set(ƎY<:X.Y x) {...} }
ƎX<:Box<Dog>.X b = new Box<Dog>(); b.set(new Poodle()); ƎX<:Dog.X d = b.get();
ƎX<:(ƎY<:Dog.List<Y>).X b = new Box<Dog>(); b.set(null); ƎX<:Dog.X d = b.get()
ƎX<:(ƎY>:Dog.List<Y>).X b = new Box<Dog>(); b.set(new Poodle()); ƎX<:Object.X d = b.get()