Covariance & anchored t ypes 1 Covariance? Wit hin t he t - PowerPoint PPT Presentation

- 10.3 - Covariance & anchored t ypes 1

Covariance? Wit hin t he t ype syst em of a programming language, a t yping rule or a t ype conver sion operat or is*: • covar iant if it preser ves t he order ing, � , of t ypes, which order s t ypes f r om more specif ic t o more generic: animal := dog (animal: ANI MAL, dog: DOG) list := st ring_list (list : LI ST [ ANY ], st ring_list : LI ST [ STRI NG ]) • cont r avar iant if it rever ses t his ordering, which orders t ypes f rom more generic t o more specif ic dog := animal st ring_list := list • novar iant if neit her of t hese apply. * ht t p:/ / en.wikipedia.org/ wiki/ Covariance_and_cont ravariance_(comput er_science) 2

The need for covariance Client CUSTOMER BEVERAGE I nherit drink : BEVERAGE ser ve ( b : BEVERAGE ) do drink := b ensure SOFT_ ALCOHOL drink = b DRI NK end MI NOR drink : SOFT_DRI NK ser ve ( b : SOFT_DRI NK ) do drink := b end 3

Defeating covariance (1) CUSTOMER BEVERAGE drink : BEVERAGE ser ve ( b : BEVERAGE ) do drink := b end SOFT_ ALCOHOL MI NOR DRI NK drink : SOFT_DRI NK b : BEVERAGE ser ve ( b : SOFT_DRI NK ) b := Pimms do drink := b end c := Shiloh c := Shiloh Pimms : ALCOHOL c . serve ( Pimms ) c . serve ( Pimms ) c : CUSTOMER c . serve ( b ) Shiloh : MI NOR 4

Defeating covariance (2) Client CUSTOMER BEVERAGE I nherit drink : BEVERAGE ser ve ( b : BEVERAGE ) do drink := b end SOFT_ ALCOHOL MI NOR DRI NK drink : SOFT_DRI NK bus : LI ST [ CUSTOMER ] ser ve ( b : SOFT_DRI NK ) school_bus : LI ST [ MI NOR ] do drink := b end bus := school_bus Gener ic Pimms : ALCOHOL conf ormance bus . it em . serve ( Pimms ) c : CUSTOMER Shiloh : MI NOR 5

Terminology Cat call: incorr ect applicat ion of a f eat ur e t o an obj ect as a result of � I ncor rect argument t ype � I nf ormat ion hiding violat ion (CAT: Changed Availabilit y or Type) f ly BI RD ?? OSTRI CH 6

Status Problem known since lat e 80s “Covar iance” t erm coined by Luca Cardelli Crit icism of init ial Eif f el design by W. Cook et al., 1989* Numerous proposals since t hen * A Proposal f or Making Eif f el Type-Saf e , ECOOP 1989 7

Mitigating mechanism 1: non-conforming inheritance class B C inherit { NONE } B f eature ... C end No polymorphism permit t ed: b1 : B b1 := c1 -- I nvalid c1 : C 8

Mitigating mechanism 2: anchored types I n practice: anchored types class CUSTOMER f eature drink : BEVERAGE ser ve ( b : BEVERAGE ) class CUSTOMER f eature do dr ink := b drink : BEVERAGE end ser ve ( b : like drink ) end do dr ink := b class MI NOR inherit end end CUSTOMER redef ine dr ink, ser ve end f eature class MI NOR inherit dr ink : SOFT_DRI NK CUSTOMER redef ine drink end ser ve ( b : SOFT_DRI NK ) f eature do dr ink : SOFT_DRI NK dr ink := b end end end 9

Anchoring to Current Also possible, in a class C : x : like Current I n any descendant D of C (including C it self ), x has t ype D 10

Mitigating mechanism 3: flat type checking An assignment T B x := y r x : T may be valid in a r out ine r of do y : T x := y a class B but not necessarily e nd in a descendant C which only redef ines x (covar iant ly) The Eif f el t ype syst em now specif ies t hat ever y class x : U must be independent ly valid U C “Flat t ype checking” 11

Unrealistic approach: contravariance CUSTOMER BEVERAGE drink : BEVERAGE ser ve ( b : BEVERAGE ) do drink := b end SOFT_ ALCOHOL MI NOR DRI NK drink : ???? Result s specialized, ar gument s ser ve ( b : ???? ) gener alized do drink := b end Solves t he pr oblem Har d t o r econcile wit h pr act ice. The wor ld does seem t o be covar iant . 12

Novariance (argument passing) C++, J ava, .NET languages Eliminat es t he problem (obviously) Forces programmers t o do t he adapt at ions t hemselves May result in br it t le/ unnecessary code 13

Previous solutions: genericity* class CUSTOMER [ DRI NK_TYPE ] *Fr anz Weber : Get t ing Class Cor r ect ness and Syst em Cor r ect ness Equivalent (How t o get covar iance r ight ) , TOOLS EUROPE 1992 14

Previous solutions: system-level validity* Considering all assignment s, comput e dynamic type set (DTS) of any var iable x . I f t her e is an assignment x := y , or argument passing, all element s of DTS of y ar e also in t he DTS of x . Advant ages: � No at t empt at cont rol f low analysis � Fixpoint algorit hm � Helps wit h opt imizat ion Disadvantages : � Pessimist ic � Not incr ement al � Dif f icult y of giving precise diagnost ics *B. Meyer: Eif f el: The Language , P r ent ice Hall, 1991 15

Type intervals CUSTOMER Pimms : ALCOHOL Shiloh : MI NOR drink : BEVERAGE ser ve ( b : BEVERAGE ) c : CUSTOMER .. MI NOR do drink := b end c := Shiloh MI NOR c . serve ( Pimms ) drink : SOFT_DRI NK ser ve ( b : SOFT_DRI NK ) - - Now invalid do drink := b end 16

Type intervals x : CUSTOMER .. CUSTOMER c : CUSTOMER .. MI NOR x := Shiloh c := Shiloh - - Now invalid x . serve ( Pimms ) c . serve ( Pimms ) - - Now invalid Rule: a call x . f ( a ), Abbreviations: with x : T . . U , must means x : T . . NONE x : T be valid when x is means LI ST [ T . . T ] LI ST [ T ] given any type in T . . U 17

The retained solution: a simplified version c : CUSTOMER x: f rozen CUSTOMER c := Shiloh x := Shiloh I nvalid OK x . serve ( Pimms ) c . serve ( Pimms ) OK I nvalid Rule: a call x . f ( a ), with x: T not f rozen, must be valid when x is given any descendant type of T 18

Genericity rule bus : LI ST [ CUSTOMER ] vbus : LI ST [ variant CUSTOMER ] school_bus : LI ST [ MI NOR ] vbus := school_bus bus := school_bus OK I nvalid vbus . ext end ( Shiloh ) bus . ext end ( Shiloh ) OK I nvalid Rule: � An assignment wit h a dif f er ent act ual generic paramet er requires t he “var iant ” mar k. � The var iant mark precludes t he use of a r out ine wit h an argument of a f or mal generic paramet er t ype 19

By the way! bus : LI ST [ CUSTOMER ] vbus : LI ST [ variant CUSTOMER ] school_bus : LI ST [ MI NOR ] vbus := school_bus bus := school_bus OK I nvalid vbus . ext end ( Shiloh ) bus . ext end ( Shiloh ) OK I nvalid bus . it em . serve ( Pimms ) ??? I nvalid since, in LI ST [ G ], it em : G is not f rozen 20

Anchored (“ like ”) declarations New result s: � “Flat t ype checking” guar ant ees t hat like Current declarat ions are saf e � b : like a , wit h a of t ype T , may be considered an b : like a abbreviat ion not f or b : T as now, but f or b : f rozen T Then only explicit (non-anchored) covariance remains! 21

Status I mplement ed and current ly being experiment ed Crit erion: must not break code unless t here is a r eal cat call r isk Need f or f or mal pr oof Proposal f or a more f lexible mechanism (“ f orget ”) 22

Covariance: summary Reconcile modeling power wit h saf et y 23