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

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

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

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

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

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 types: @Dog

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

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

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

Is there a connection? Ǝ Ǝ Ǝ Ǝ Ǝ Ǝ Ǝ

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?

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

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

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

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 </: @Dog

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

Ǝ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

ƎFGJ

Ǝ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

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

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

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

Understanding Wildcards

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

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

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

Thank you! Questions? ncameron@ecs.vuw.ac.nz

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

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