Subtyping Thomas Wies wies@mpi-sb.mpg.de Seminar: Types and - PowerPoint PPT Presentation

Subtyping Thomas Wies wies@mpi-sb.mpg.de Seminar: Types and Programming Languages, WS 02/03 Pierce, ch. 15-18 Types and Programming Languages 1

O VERVIEW ➀ The subtype relation ➁ Typechecking ➂ Extensions: references, casts ➃ Case study: featherweight Java O VERVIEW 2

F RAMEWORK Language used in this talk: simply typed lambda-calculus + records: Example: r = ( λ r : { x : Nat , y : Nat } . r ) { x = 1 , y = 2 } ; ⊲ r : { x : Nat , y : Nat } r . x ; ⊲ 1 : Nat in the context of imperative objects: simply typed lambda-calculus + records + references F RAMEWORK 3

M OTIVATION Problem: Simply typed lambda-calculus is often to restrictive. Example: ( λ r : { x : Nat } . r . x ) { x = 0 , y = 1 } is not well-typed. Intuition: • Subset semantics: whenever S is a subset of T , then any term of type S should also be of type T . • More general: whenever it is safe to use a term of type S in a context of type T , then S is a subtype of T , written S < : T . In the example: { x : Nat , y : Nat } < : { x : Nat } M OTIVATION 4

W HAT IS NEEDED ? • We have to extend our typing rules: Γ ⊢ t : S S < : T (T-S UB ) Γ ⊢ t : T • We have to formalize what S < : T means. Notice: Evaluation is not effected by the introduction of subtyping. W HAT IS NEEDED ? 5

T HE S UBTYPE R ELATION Top: S < : Top (S-T OP ) Reflexivity: S < : S (S-R EFL ) Transitivity: S < : U U < : T (S-T RANS ) S < : T Arrow-Types: T 1 < : S 1 S 2 < : T 2 S 1 → S 2 < : T 1 → T 2 (S-A RROW ) T HE S UBTYPE R ELATION 6

T HE S UBTYPE R ELATION (2) Record deepening: ∀ i : S i < : T i (S-R CD D EPTH ) i ∈ 1 .. n } < : { l i : T i i ∈ 1 .. n } { l i : S i Record widening: i ∈ 1 .. n + k } < : { l i : T i i ∈ 1 .. n } { l i : T i (S-R CD W IDTH ) Record permutation: i ∈ 1 .. n } is a permutation of { l i : T i i ∈ 1 .. n } { k i : S i (S-R CD P ERM ) i ∈ 1 .. n } < : { l i : T i i ∈ 1 .. n } { k i : S i T HE S UBTYPE R ELATION (2) 7

E XAMPLE : A S UBTYPE D ERIVATION Derivation of: ⊢ ( λ r : { x : Top } . r . x ) { x = 0 , y = 1 } : Top E XAMPLE : A S UBTYPE D ERIVATION 8

T YPE S AFETY Type safety is preserved in presence of subtyping: If Γ ⊢ t : T and t → t ′ , then Γ ⊢ t ′ : T Theorem (Preservation): Theorem (Progress): If t is a closed, well-typed term, then either t is a value or t → t ′ . T YPE S AFETY 9

T YPECHECKING • Algorithmic subtyping • Algorithmic typing T YPECHECKING 10

A T YPECHECKER WITH S UBTYPING How to implement a subtypechecker checking S < : T for two types S and T ? Problem: S < : S (S-R EFL ) S < : U U < : T (S-T RANS ) S < : T S and T match any types. ➜ Rules can be applied in any situation. ➜ The subtype relation considered so far can not be used to im- plement a subtypechecker directly. → S < : T , Idea: Introduce an algorithmic subtype relation ⊢ → S < : T iff S < : T s.t. ⊢ A T YPECHECKER WITH S UBTYPING 11

A LGORITHMIC S UBTYPING Observations: • Reflexivity is not needed for typechecking. ➜ drop S-R EF • Transitivity is only needed for record-types. ➜ merge record-rules in one single rule ➜ drop S-T RANS New rule for record-subtyping: i ∈ 1 .. n } ⊆ { k j j ∈ 1 .. m } → S j < : T i { l i k j = l i ⇒ ⊢ (SA-R CD ) j ∈ 1 .. m } < : { l i : T i i ∈ 1 .. n } → { k j : S j ⊢ • S-T OP and S-A RROW do not change. A LGORITHMIC S UBTYPING 12

A LGORITHMIC T YPING For typechecking we have a similar problem: Γ ⊢ t : S S < : T (T-S UB ) Γ ⊢ t : T t matches any term, hence the rule T-S UB fires on any term. ➜ We need an algorithmic typing relation Γ ⊢ → t : T A LGORITHMIC T YPING 13

A LGORITHMIC T YPING (2) Observation: • T-S UB is only needed to match the argument- and domain-types in application terms. ➜ merge T-S UB into T-A PP New rule for applications: → t 1 : T 11 → T 12 → t 2 : T 2 → T 2 < : T 11 Γ ⊢ Γ ⊢ ⊢ (TA-A PP ) → t 1 t 2 : T 12 Γ ⊢ Theorem: Algorithmic typing is sound and complete. ➀ if Γ ⊢ → t : T , then Γ ⊢ t : T . ➁ if Γ ⊢ t : T , then Γ ⊢ → t : S for some S < : T . A LGORITHMIC T YPING (2) 14

S UBTYPING AND E XTENSIONS • References • Up- and down-casts S UBTYPING AND E XTENSIONS 15

S UBTYPING AND R EFERENCES What conditions must hold in order to get Ref S < : Ref T ? Example: ( λ r : Ref { x : Nat , y : Nat } . ! r . x ) ( ref { y = 0 } ) will go wrong. ➜ We need S < : T in order to get safe dereferences. ( λ r : Ref { x : Nat , y : Nat } . r := { x = 1 } ; ! r . y ) ( ref { x = 0 , y = 1 } ) will go wrong, too. ➜ We also need T < : S in order to get safe assignments. Simple inference rule: S < : T T < : S Ref S < : Ref T (S-R EF ) S UBTYPING AND R EFERENCES 16

R EFERENCES REFINED Decompose Ref T in two new types • Source T : capability to read from a reference cell • Sink T : capability to write into a reference cell and modify the typing rules for references accordingly: Γ | Σ ⊢ t : Source T (T-D EREF ) Γ | Σ ⊢ ! t : T Γ | Σ ⊢ t 1 : Sink T Γ | Σ ⊢ t 2 : T (T-A SSIGN ) Γ | Σ ⊢ t 1 := t 2 : Unit R EFERENCES REFINED 17

R EFERENCES REFINED (2) Now, subtyping for references is easy: S < : T Source S < : Source T (S-S OURCE ) T < : S Sink S < : Sink T (S-S INK ) Ref is just a subtype of both Source and Sink : Ref T < : Source T (S-R EF S OURCE ) Ref T < : Sink T (S-R EF S INK ) R EFERENCES REFINED (2) 18

A SCRIPTION AS A C ASTING O PERATOR Idea: use ascription operator t as T to perform type casts. Γ ⊢ t : T Γ ⊢ t as T : T (T-A SCRIBE ) Up-casts Application: information-hiding. Ascription + subsumption immediately gives us Up-casts. Example: { x = 0 , y = 1 } as { x : Nat } is well-typed and y is hidden in the context of the ascribed term. Notice: up-casts do not require ascription, they can be performed using lambda-terms, too. A SCRIPTION AS A C ASTING O PERATOR 19

A SCRIPTION AS A C ASTING O PERATOR (2) Down-casts Application: down-casts + Top provide simple form of polymorphism. Example: container classes in Java. Down-casts require an additional typing-rule: Γ ⊢ t : S Γ ⊢ t as T : T (T-D OWN C AST ) Problem: down-casts may be unsound. Solution: Add dynamic type tests to the evaluation-rules for ascrip- tion. A SCRIPTION AS A C ASTING O PERATOR (2) 20

C OERCION S EMANTICS Problem: subtyping may result in performance penalties on the low- level language implementation. Example: How to perform efficiently record-field accesses in the presence of a permutation rule? Idea: coercion semantics: Use the type- and subtype-derivation trees to generate additional code for type conversions. C OERCION S EMANTICS 21

C ASE S TUDY : F EATHERWEIGHT J AVA • Interfaces • Inheritance • Subtyping • self and open recursion C ASE S TUDY : F EATHERWEIGHT J AVA 22

I MPERATIVE O BJECTS What are the essential features of imperative objects? • Multiple representations – same interface, but different implementations • Encapsulation and information hiding – internal state only accessible via interface – concrete representation hidden • Inheritance – classes are used as templates for object instantiation – derived sub-classes can selectively share code with their super-classes I MPERATIVE O BJECTS 23

F EATURES OF I MPERATIVE O BJECTS ( CONT ’ D .) • Subtyping – objects of sub-classes can be used in any super-class con- text • self and open recursion – methods are allowed to invoke other methods of the same object via self or this – in particular: super-classes may invoke methods declared in sub-classes (late-binding). F EATURES OF I MPERATIVE O BJECTS ( CONT ’ D .) 24

A S IMPLE J AVA E XAMPLE Simple implementation of a counter in Java: class Counter { private int x; public Counter() { super (); x=1;} public int get () { return x;} public void inc () { x++;} } Question: How can we mimic this within the simply typed lambda- calculus with subtyping? A S IMPLE J AVA E XAMPLE 25

I NTERFACES The interfaces can be described by using record types: • a label with functional type for each public method • a label for each public instance variable with appropriate type In the example: Counter = { get : Unit → Nat , inc : Unit → Unit } ; I NTERFACES 26

O BJECTS A counter object can be implemented now by allocating the instance variable and constructing the method table: c = let x = ref 1 in { get = λ _ : Unit . ! x , inc = λ _ : Unit . x := succ (! x ) } ; ⊲ c : Counter ( c . inc unit ; c . inc unit ; c . get unit ); ⊲ 3 : Nat O BJECTS 27

A S IMPLE C LASS Define a representation type for the instance variables: CounterRep = { x : Ref Nat } ; The counter class now abstracts over the counter representation: counterClass = λ r : CounterRep . { get = λ _ : Unit . !( r . x ) , inc = λ _ : Unit . x := succ (!( r . x )) } ; ⊲ counterClass : CounterRep → Counter New objects can be instantiated via an object generator: newCounter = λ _ : Unit . let r = { x = ref 1 } in counterClass r ; ⊲ newCounter : Unit → Counter A S IMPLE C LASS 28

I NHERITANCE IN J AVA Example of an inherited class in Java: class ResetCounter extends Counter { public ResetCounter() { super ();} public void reset () { x = 1;} } I NHERITANCE IN J AVA 29