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

1

• 10.3 -

Covariance & anchored t ypes

2

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
• rder 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)

3

The need for covariance

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

4

Defeating covariance (1)

CUSTOMER MI NOR BEVERAGE SOFT_ DRI NK ALCOHOL

Pimms : ALCOHOL c : CUSTOMER Shiloh : MI NOR

c.serve ( Pimms) c := Shiloh c.serve (b ) b := Pimms

b : BEVERAGE

drink : BEVERAGE ser ve (b : BEVERAGE ) do drink := b end drink : SOFT_DRI NK ser ve (b : SOFT_DRI NK ) do drink := b end

c.serve ( Pimms) c := Shiloh

5

Defeating covariance (2)

CUSTOMER MI NOR BEVERAGE SOFT_ DRI NK ALCOHOL drink : BEVERAGE ser ve (b : BEVERAGE ) do drink := b end drink : SOFT_DRI NK ser ve (b : SOFT_DRI NK ) do drink := b end

bus.it em.serve ( Pimms) bus : LI ST [CUSTOMER]

school_bus : LI ST [MI NOR]

Client I nherit

Pimms : ALCOHOL c : CUSTOMER Shiloh : MI NOR

bus := school_bus Gener ic

conf ormance

6

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

• r Type)

BI RD OSTRI CH

f ly ??

7

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

8

Mitigating mechanism 1: non-conforming inheritance

class C inherit {NONE } B f eature ... end No polymorphism permit t ed: b1 := c1

• - I nvalid

B C

b1: B c1: C

9

class CUSTOMER f eature drink : BEVERAGE ser ve (b : like drink ) do dr ink := b end end

Mitigating mechanism 2: anchored types

class CUSTOMER f eature drink : BEVERAGE ser ve (b : BEVERAGE ) do dr ink := b end end class MI NOR inherit CUSTOMER redef ine dr ink, ser ve end f eature dr ink : SOFT_DRI NK ser ve (b : SOFT_DRI NK ) do dr ink := b end end class MI NOR inherit CUSTOMER redef ine drink end f eature dr ink : SOFT_DRI NK end

I n practice: anchored types

10

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

11

Mitigating mechanism 3: flat type checking An assignment x := y may be valid in a r out ine r of a class B but not necessarily 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 must be independent ly valid “Flat t ype checking”

B C

r

do x := y end

x : T y : T x : U

T U

12

Unrealistic approach: contravariance

Result s specialized, ar gument s gener alized 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 . CUSTOMER MI NOR BEVERAGE SOFT_ DRI NK ALCOHOL drink : BEVERAGE ser ve (b : BEVERAGE ) do drink := b end drink : ???? ser ve (b :????) do drink := b end

13

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

14

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

15

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,

• r 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

16

Type intervals

CUSTOMER MI NOR drink : BEVERAGE ser ve (b : BEVERAGE ) do drink := b end drink : SOFT_DRI NK ser ve (b : SOFT_DRI NK ) do drink := b end

Pimms : ALCOHOL

c.serve ( Pimms) c := Shiloh

c : CUSTOMER..MI NOR Shiloh : MI NOR

• - Now invalid

17

Type intervals c.serve (Pimms) c := Shiloh

c : CUSTOMER..MI NOR

• - Now invalid

Rule: a call x. f (a), with x : T. . U, must be valid when x is given any type in T. . U Abbreviations: x : T means x : T. . NONE LI ST [T ] means LI ST [T. . T ] x : CUSTOMER..CUSTOMER

x.serve (Pimms) x := Shiloh

• - Now invalid

18

The retained solution: a simplified version c.serve (Pimms) c := Shiloh

c : CUSTOMER x: f rozen CUSTOMER OK Rule: a call x. f (a), with x: T not f rozen, must be valid when x is given any descendant type of T

x.serve (Pimms) x := Shiloh

I nvalid OK I nvalid

19

Genericity rule vbus.ext end (Shiloh) vbus := school_bus

bus : LI ST [CUSTOMER ] vbus : LI ST [variant CUSTOMER ] school_bus : LI ST [MI NOR] OK 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 I nvalid OK I nvalid

bus.ext end (Shiloh) bus := school_bus

20

By the way! vbus.ext end (Shiloh) vbus := school_bus

bus : LI ST [CUSTOMER ] vbus : LI ST [variant CUSTOMER ] school_bus : LI ST [MI NOR] OK I nvalid I nvalid

bus := school_bus

OK

bus.ext end (Shiloh)

I nvalid since, in LI ST [G], it em : G is not f rozen

bus.it em.serve (Pimms)

???

21

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

abbreviat ion not f or b : T as now, but f or Then only explicit (non-anchored) covariance remains! b : like a b : f rozen T

22

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

23

Covariance: summary

Reconcile modeling power wit h saf et y