Lecture 9: When is ST safe? Killer Bear

1. Lecture 9: When is ST safe? Killer Bear What’s the difference between a Black Bear and a Grizzly Bear? Climber KillingBear When you climb up the tree, the Grizzly climbs up after you. The Black Bear knocks down the tree. (Which is the behavioral subtype?) David Evans http://www.cs.virginia.edu/~evans BlackBear GrizzlyBear CS655: Programming Languages University of Virginia Computer Science

2. Menu • Wrap-up “What is Object-Oriented Programming?” • Behavioral Notion of Subtyping • Elevator Speeches (scattered) • Turn in meeting preferences and mock trial request forms at end of class University of Virginia CS 655

3. Last time • Defined subtyping as subsumption • Showed typing judgments that support subtype polymorphism • Some language features that support subtype polymorphism: • Dynamic type-directed method dispatch • Subclassing (Implementation inheritance) University of Virginia CS 655

4. Multiple Inheritance Node has typeCheck x := a + b; Declaration has enterSymbol Assignment has generateCode int x; InitializedDeclaration has enterSymbol, generateCode int x := a + b; University of Virginia CS 655

5. Smalltalk Design Principles Personal Mastery:If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Storage Management:To be truly "object-oriented", a computer system must provide automatic storage management. Uniform Metaphor:A language should be designed around a powerful metaphor that can be uniformly applied in all areas. University of Virginia CS 655

6. Smalltalk Design Principles 2 Operating System:An operating system is a collection of things that don't fit into a language. There shouldn't be one. Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones. University of Virginia CS 655

7. Stroustrup’s Conclusions “Object-oriented programming is programming with inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction. These techniques need proper support to be effective. Data abstraction primarily needs support in the form of language features and object-oriented programming needs further support from a programming environment. To be general purpose, a language supporting data abstraction or object-oriented programming must enable effective use of traditional hardware.” University of Virginia CS 655

8. My Conclusions • Object-Oriented Programming is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have a way to declare ST and the type judgment: , ST A E :S [subsumption] A E : T Other language features can help, but we aren’t yet sure what the right ones are: dynamic dispatch, implementation inheritance, mixins, automated delegation, etc. University of Virginia CS 655

9. Analogies • Structured Programming is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have structured scopes and control statements (e.g., while, for, if, blocks, procedures) • Data Abstraction is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have type checking by name and mechanisms for restricting access Speech! University of Virginia CS 655

10. What does it mean for ST to be safe? • Liskov & Wing: “objects of the subtype ought to behave the same as those of the supertype as far as anyone or any program using supertype objects can tell.” • For all programs P, if P behaves correctly when passed a T, it behaves correctly when passed an S. • For all programs P, if P can be shown to satisfy its specification using the specification of T, then P can be shown to satisfy its specification using the specification of S. Too Strong University of Virginia CS 655

11. L & W’s Subtype Requirement • Let (x) be a property provable about objects x of type T. Then (y) should be true for objects y of type S where S is a subtype of T. • Same meaning? For all programs P, if P can be shown to satisfy its specification using the specification of T, then P can be shown to satisfy its specification using the specification of S. University of Virginia CS 655

12. Type Specification • Description of type’s value space • Type invariant and history properties (constraint) • How different from rep invariant? • For each method: • Behavior in terms of pre-conditions and post-conditions • No creators – allows subtypes to provide different creators • Need to prove creators establish invariant and constraint University of Virginia CS 655

13. Two-Tiered Specification • Separate interface-level specification from sort specification • Specs in paper are interface-level specifications only: bag = type uses BBag (bag for B) ... get = proc () returns (int) requires bpre.elems  { } What does this mean? University of Virginia CS 655

14. LSL Specification Bag (E, C) : trait introduces { } :  C; insert : E, C  C; count : E, C  Int asserts C generated by {}, insert C partitioned by count  b: C, e, e1, e2: E count (e, {}) == 0; count (e1, insert (e2, b)) == count (e1, b) + (if e1 = e2 then 1 else 0) BBag (B) tuple of bound: Int, elems: Bag (Int, B for C) University of Virginia CS 655

15. Subtype Relation: ST is safe if: • Subtype methods preserve the supertype methods’ behavior: • Signature: • Contravariance of arguments, covariance of result (typing rule we saw last time) • Exceptions by ms are contained in set of exceptions signed by mT University of Virginia CS 655

16. Subtype Relation 2: ST is safe if: • Methods rule: • Pre-condition  x : s mT.pre [ A(xpre) / xpre ]  mS.pre Replace every xpre in mT.pre with A(xpre). Abstraction function, A: s  t. • Post-condition mS.post  mT.post [ A(xpre) / xpre, A(xpost) / xpost] “contravariance – subtype is weaker” “covariance – subtype is stronger” University of Virginia CS 655

17. Subtype Relation 3: ST is safe if: • a • Subtypes preserve supertype properties • For all states p and q such that p precedes q • Invariant Rule IS IT [ A(xp) / xp] • Constraint Rule CS CT [ A(xp) / xp, A(xq) / xq ] “covariance – subtype is stronger” University of Virginia CS 655

18. Example • Liskov & Wing showed stack  bag • Is bset  bag? • Is uset  bag? • Is uset  bset? Is bset  uset? • Set specifications in the Lecture 9 supplement page • Bag in Liskov & Wing, Figure 1 University of Virginia CS 655

19. set = type uses BSet (set for S) for all s: set invariant max(sp.elements) <= sp.limit, min (sp.elements) >= 0. constraintsp.limit = sq.limit insert = proc (i: int) requires i <= sp.limit  i >= 0. modifies s ensures spost.limit = spre.limit  i  spost.elements   x:int x  spost.elements  x  spre.elements  x = i University of Virginia CS 655

20. contains = proc (el: int) returns (bool) ensures result = el  s choose = proc () returns (int) requires spre.elements  {} modifies s ensures spost.elements = spre.elements – result  result  spre.elements  spost.limit = spre.limit size = proc() returns (int) ensures result = | s.elements | equal = proc (t: set) returns (bool) ensures result = (s = t) University of Virginia CS 655

21. Subtype Checklist: bset  bag? • A type is: < set of objects, set of values, set of methods > set = <Oset, BSet, { insert, contains, choose, size, equal } > bag = <Obag, BBag, { put, get, card, equal } > • A : value of set  value of bag • A : BSet  BBag • s : BSet; A (s) = < s.elems, s.limit > • Renaming: • R(insert) = put R(choose) = get • R(size) = card R(equal) = equal University of Virginia CS 655

22. Check method choose  get • Signatures:get =proc () returns (int); choose = proc () returns (int) • Pre-condition of get pre-condition of choose x : BSet get.pre [ A(xpre) / xpre ]  choose.pre bpre.elems  {} [A(bpre) / bpre ]  spre.elems  {} • s : BSet; A (s) = < s.elements, s.limit > so we can replace bpre.elems with spre.elems and the implication holds. • Post-condition of choose post-condition of get • Can prove with similar renaming University of Virginia CS 655

23. Check method insert  put • Signatures: put =proc (i: int); insert = proc (i: int) • Pre-condition of put pre-condition of insert • x : BSet put.pre [ A(xpre) / xpre ]  insert.pre | A(spre).elems | < A(spre).bound  i <= sp.limit  i >= 0 • NO! The subtype method has a stronger pre-condition, so it is not a subtype. University of Virginia CS 655

24. Does this make sense? • Intuition: subtype is unsafe, if there is some program written for the supertype that can tell the difference • Here’s one: put (999235);  insert (999235); University of Virginia CS 655

25. uset  bag? • A : S  T • A : Set  BBag • s : Set; A (s) = < s, > • Renaming: • R(insert) = put R(choose) = get • R(size) = card R(equal) = equal • Check method choose  get (same as bset) 8 University of Virginia CS 655

26. Check method insert  put • Pre-condition of put pre-condition of insert • x : BSet put.pre [ A(xpre) / xpre ]  insert.pre = true • Post-condition of insert post-condition of put insert.post put.post [ A(xpre) / xpre, A(xpost) / xpost] (spost.elements = spre.elements  { i }) • (bpost.elems = bpre.elems  { i }  bpost.bound = bpre.bound) [ A(bpre) / bpre, A(bpost) / bpost] recall: A (s) = < s, infinity> so (spost.elems = spre.elems  { i }  infinity = infinity University of Virginia CS 655

27. Check Invariant • Need to show: IS IT [ A(xp) / xp] true  (| bp.elems | <= bp.bound) [ A(bp) / bp] true  (| <s.elements, infinity>.elems | <= <s.elements, infinity>.bound true  true • Similar for constraint • uset is a subtype of bag! Yippee! University of Virginia CS 655

28. Summary Questions • uset  bset?, bset  uset? • Does the Liskov/Wing subtype relation definition match intuition? • Is it useful? University of Virginia CS 655

29. Charge • Return both request forms before 5pm today • Don’t stop working on your projects just because you have position papers, readings, problem sets, other classes, etc. to do. • Next time: pragmatic aspects of OO languages - comparison of Sather, Eiffel, Java and C++ University of Virginia CS 655