1 / 34

Subtyping

Subtyping. Chapter 15 Benjamin Pierce Types and Programming Languages. Varieties of Polymorphism . Parametric polymorphism A single piece of code is typed generically Imperative or first-class polymorphism ML-style or let-polymorphism

vince
Télécharger la présentation

Subtyping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Subtyping Chapter 15 Benjamin Pierce Types and Programming Languages

  2. Varieties of Polymorphism • Parametric polymorphism A single piece of code is typed generically • Imperative or first-class polymorphism • ML-style or let-polymorphism • Ad-hoc polymorphism The same expression exhibit different behaviors when viewed in different types • Overloading • Multi-method dispatch • Intentional polymorphism • Subtype polymorphism A single term may have many types using the rule of subsumption allowing to selectively forget information

  3. Simple Typed Lambda Calculus t ::= terms x variable  x: T. t abstraction t t application T::= types  T  T types of functions

  4. x : T  (T-VAR)  x : T , x : T1 t2 : T2 (T-ABS)  x : T1. t2: T1 T2 Type Rules  t : T t ::= terms x variable  x: T. t abstraction  t2 : T11  t1 : T11T12 T::= types  T  T types of functions (T-APP)  t1 t2 : T12 ::= context   empty context , x : T term variable binding

  5. Records New syntactic forms New Evaluation Rules extends  t ::= …. Terms: {li=tii  1..n} recordt.l projection {li=vii  1..n }. lj  vj(E-ProjRCD)  t:{ li: Tii  1..n } For each i ti : Ti t  t’ (T-Tuple) (T-Proj) v ::= …. Values: {li=vi i  1..n} records  t.lj : Tj  {li=tii  1..n} : { li: Tii  1..n } (E-Proj} t.l t’.l T ::= …. types: {li:Tii  1..n } record type New typing rules tj  t’j (E-Tuple) {li=vii  1..j-1, li=tii  j..n}  {li=vii  1..j-1,lj=t’j,lk=tkk  j+1..n}

  6. Record Example (r : {x: Nat}. r.x) {x=0, y=0 } {x: Nat, y: Nat} <: {x: Nat} S <:T  t : S (T-SUB)  t : T  t2 : T11  t1 : T11T12 (T-APP)  t1 t2 : T12

  7. Healthiness of Subtypes S <: S (S-REFL) U <:T S <: U (S-TRANS) S <:T

  8. Width Record Subtyping {li:Tii 1..n+k } <: {li:Tii 1..n } (S-RCDWIDTH) {x: Nat} has at least the field x of type Nat {x: Nat, y : Nat} has at least the field x of type Nat and the field y of type Nat {x: Nat, y: Bool} has at least the field x of type Nat and the field y of type Bool {x: Nat, y: Nat} <: {x: Nat} {x: Nat, y: Bool} <: {x: Nat}

  9. Record Depth Subtyping For each i Si <: Ti (S-RCDEPTH) {li:Sii 1..n } <: {li:Tii 1..n }

  10. {x: {a: Nat, b: Nat}, y: {m:Nat}} <: {x: {a: Nat}, y: {}} {a:Nat, b: Nat} <: {a: Nat} (S-RCDWIDTH) {m: Nat} <: {} (S-RCDWIDTH) (S-RCDEPTH) {x: {a: Nat, b: Nat}, y: {m: Nat}} <: {x: {a: Nat}, y: {}}

  11. {x: {a: Nat, b: Nat}, y: Nat} <: {x: {a: Nat}, y: Nat}} {a:Nat, b: Nat} <: {a: Nat} (S-RCDWIDTH) Nat <: Nat (S-REFL) (S-RCDEPTH) {x: {a: Nat, b: Nat}, y: Nat} <: {x: {a: Nat}, y: {}}

  12. {x: {a: Nat, b: Nat}, y: {m: Nat}} <: {x: {a: Nat}} {x: {a:Nat, b: Nat}}, {y: {m: Nat}} <: {x: {a: Nat}, b:Nat}} (S-RCDWIDTH) {x: {a: Nat, b: Nat} <: {x: {a: Nat}} (S-RCDEPTH) {a: Nat, b: Nat} <: {a: Nat} (S-RCDWIDTH) (S-TRANS) {x: {a: Nat, b: Nat}, y: {m: Nat}} <: {x: {a: Nat}}

  13. Field Permutation {kj:Sjj  1..n } is a permutation of {li:Tii 1..n } (S-RCDPERM) {kj:Sjj  1..n } <: {li:Tii 1..n }

  14. Record Subtying • Forgetting fields (S-RCDWIDTH) • Forgetting subrecords (S-RCDEPTH) • Reordering fields (S-RCDPERM)

  15. S1 <: T1 (S-ARROWN) S1 S2 <: T1 T2 Naïve Handling of Functions S2 <: T2 n:{x: Nat, y: Nat}  n.x +1 : Nat n:{x: Nat, y: Nat}  n.y +2 : Nat} (T-RCD) n:{x: Nat, y: Nat}  {x: n.x +1 , y: n.y +2}) : {x: Nat, y: Nat} (S-ARROWN) {x:Nat, y: Nat}{x:Nat, y: Nat} <: {x: Nat} {x: Nat, y: Nat} {x:Nat, y: Nat} <: {x: Nat} (S-RCDWIDTH) {x:Nat, y: Nat} <: {x: Nat, y: Nat} (S-REFL) (T-ABS) (T-SUB)  n:{x: Nat, y: Nat}. {x: n.x +1 , y: n.y +2}) : {x: Nat, y: Nat}  {x: Nat, y: Nat}  n:{x: Nat, y: Nat}. {x: n.x +1 , y: n.y +2}) : {x: Nat}  {x: Nat, y: Nat}  1 : Nat (T-RECD) (T-APP)  {x: 1} : {x: Nat}  n:{x: Nat, y: Nat}. {x: n.x +1 , y: n.y +2}) {x:1} : {x: Nat, y: Nat}

  16. T1 <: S1 (S-ARROW) S1 S2 <: T1 T2 Handling of Functions S2 <: T2 • Arguments types are handled in reversed way (contravariant) • Result types are handled in the same direction (covariant)

  17. Top type T <: Top (S-TOP)

  18. Properties of the subtyping relation • Preorder on types

  19. t2 t’2 (E-APP2) v1 t2 v1t’2 SOS for Simple Typed Lambda Calculus t ::= terms x variable  x: T. t abstraction t t application t1 t2 t1 t’1 (E-APP1) t1 t2 t’1 t2 v::= values  x: T. t abstraction values ( x: T11. t12) v2 [x v2] t12 (E-APPABS) T::= types  Top maximum type T  T types of functions

  20. x : T  (T-VAR)  x : T , x : T1 t2 : T2 (T-ABS)  x : T1. t2: T1 T2 T1 <: S1 (S-ARROW) S1 S2 <: T1 T2 Type Rules  t : T S2 <: T2 S <: S (S-REFL) U <:T S <: U  t2 : T11  t1 : T11T12 (S-TRANS) (T-APP) S <:T  t : S S <:T (T-SUB)  t1 t2 : T12  t : T T <: Top (S-TOP)

  21. Records Evaluation Rules extends  syntactic forms {li=vii  1..n }. lj  vj(E-ProjRCD) t ::= …. Terms: {li=tii  1..n} recordt.l projection {kj:Sjj  1..n } is a permutation of {li:Tii 1..n } For each i Si <: Ti (S-RCDEPTH) (S-RCDPERM) {kj:Sjj  1..n } <: {li:Tii 1..n } {li:Sii 1..n } <: {li:Tii 1..n }  t:{ li: Tii  1..n } For each i ti : Ti t  t’ (T-Proj) (T-Tuple) v ::= …. Values: {li=vi i  1..n} records  {li=tii  1..n} : { li: Tii  1..n }  t.lj : Tj t.l t’.l (E-Proj} T ::= …. types: {li:Tii  1..n } record type New subtyping rules typing rules {li:Tii 1..n+k } <: {li:Tii 1..n } (S-RCDWIDTH) tj  t’j (E-Tuple) {li=vii  1..j-1, li=tii  j..n}  {li=vii  1..j-1,lj=t’j,lk=tkk  j+1..n}

  22. r : T’ = {x: T=Nat} (T-VAR) r :{x: Nat} r.x : T (T-ABS) Example {x:Nat, y:Nat} <: {x:Nat} (S-RCDWIDTH) r :{x: Nat}r : T’ = {… x: T …} 0: Nat 0: Nat (T-Tuple) (T-Proj)  {x=0, y=0} : S={ x: Nat, y: Nat} S <:{x : Nat} {x=0, y=0}: S (T-SUB)  r :{x: Nat}. r.x : {x: Nat} T  {x=0, y=0}: {x : Nat} (T-APP) (r : {x: Nat}. r.x) {x=0, y=0 } : T

  23. Properties of the type system(15.3) • Uniqueness of types • Linear time type checking • Type Safety • Well typed programs cannot go wrong • No undefined semantics • No runtime checks • If t is well typed then either t is a value or there exists an evaluation step t  t’ [Progress] • If t is well typed and there exists an evaluation step t  t’ then t’ is also well typed [Preservation]

  24. Upcasting (Information Hiding) • Special case of ascription S <: T t: S (T-SUB) t : T (T-ASCRIBE)  t as T: T

  25. Downcasting • Generate runtime assertion • But the typechecker can assume the right type t : S (T-DOWNCAST) t as T : T Progress is no longer guaranteed Can replace downcasts by dynamic type check v :T (E-DOWNCAST) v as T  v  t1 : S , x: T t2: U  t3: U (T-TYPETEST)  if t1in T then x  t2else t3: U v :T v :T (E-TYPETESTF) (E-TYPETESTT) if v in T then x  t2 else t3 [x v] t2 if v in T then x  t2 else t3 t3 (E-ASCRIBE) v as T  v

  26. Downcasting vs. Polymorphism • Downcasting is useful for reflection • Polymorphism saves the need for downcasts in most cases • reverse : X: list X  list X • Polymorphism leads to shorter and more secure code • Polymorphism can have better performance • Downcasting complicates the runtime system • Polymorphism complicates language definition • The interactions between polymorphism and subtyping complicates type checking/inference • Irrelevant for Java

  27. Variants Modified syntactic forms t ::= …. Terms: <l=t> as T tagging case t of <li = xi>  tii 1..n case v ::= …. Values: <l=v> as T tagged value T ::= …. types: <li = Tii 1..n> type of variants Evaluation Rules extends  ti  t’i (E-VARIANT) <l i=ti> as T <li=t’i>as T case (<lj = v> as T) of <li = xi>  tii 1..n  [xjv] tj (E-CaseVariant) t  t’ (E-CASE) case t of <li = xi>  tii 1..n  case t’ of <li = xi>  tii 1..n

  28. Modified Type rules for Variants New subtyping rules Modified syntactic forms t ::= …. Terms: <l=t> as T tagging case t of <li = xi>  tii 1..n case <li:Tii 1..n > <: <li:Tii 1..n +k> (S-VARIANTWIDTH) <kj:Sjj  1..n > is a permutation of <li:Tii 1..n > For each i Si <: Ti (S-VARIANTDEPTH) (S-VARIANTPERM) <li:Sii 1..n > <: <li:Tii 1..n > <kj:Sjj  1..n > <: <li:Tii 1..n > tj : Tj v ::= …. Values: <l=v> as T tagged value (T-VARIANT) <l j=tj>as <li = Tii 1..n> : < lj= Tj> T ::= …. types: <li = Tii 1..n> type of variants For each i , xi :Titi : T  t : <li = Tii 1..n> modified typing rules (T-CASE) case t of <li = xi>  tii 1..n : T

  29. S <: T (S-List) List S <: List T Lists

  30. S <: T T <: S (S-Ref) ref S <: ref T References

  31. S <: T T <: S S <: T (S-Array) (S-ArrayJava) Array S <: Array T Array S <: Array T Arrays

  32. Base Types Bool <: Nat (S-BoolNat)

  33. Coercion Semantics for Subtyping (15.6) • The compiler can perform conversions between types • Sometimes at compile time • Subtyping is no longer transparent • Improve performance

  34. Summary • Subtyping improves reuse • Tricky semantics • Complicates type checking/inference • Well understood for many language features

More Related