Lecture 9: When is S  T safe?
Killer
Bear
Climber
KillingBear
BlackBear
GrizzlyBear
What’s the difference
between a Black Bear and a
Grizzly Bear?
When you climb up the tree,
the Grizzly climbs up after
you. The Black Bear knocks
down the tree. (Which is the
behavioral subtype?)
CS655: Programming Languages
David Evans
University of Virginia
http://www.cs.virginia.edu/~evans
Computer Science
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
27 July 2016
University of Virginia CS 655
2
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)
27 July 2016
University of Virginia CS 655
3
Multiple Inheritance
Node
has typeCheck
int x; Declaration
Assignment
has enterSymbol
has generateCode
x := a + b;
InitializedDeclaration
has enterSymbol, generateCode
int x := a + b;
27 July 2016
University of Virginia CS 655
4
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 "objectoriented", 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.
27 July 2016
University of Virginia CS 655
5
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.
27 July 2016
University of Virginia CS 655
6
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.”
27 July 2016
University of Virginia CS 655
7
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:
A E : S, S  T
[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.
27 July 2016
University of Virginia CS 655
8
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
Speech!
restricting access
27 July 2016
University of Virginia CS 655
9
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.
Too Strong
• 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.
27 July 2016
University of Virginia CS 655
10
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.
27 July 2016
University of Virginia CS 655
11
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 postconditions
• No creators – allows subtypes to provide
different creators
– Need to prove creators establish invariant and
constraint
27 July 2016
University of Virginia CS 655
12
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  { }
27 July 2016
What does this mean?
University of Virginia CS 655
13
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)
27 July 2016
University of Virginia CS 655
14
Subtype Relation: S  T is safe if:
1. 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
27 July 2016
University of Virginia CS 655
15
Subtype Relation 2: S  T is safe if:
• Methods rule:
– Pre-condition “contravariance – subtype is weaker”

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 “covariance – subtype is stronger”
mS.post  mT.post [ A(xpre) / xpre, A(xpost) / xpost]
27 July 2016
University of Virginia CS 655
16
Subtype Relation 3: S  T is safe if:
1. a
2. 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”
27 July 2016
University of Virginia CS 655
17
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
27 July 2016
University of Virginia CS 655
18
set = type
uses BSet (set for S)
for all s: set
invariant max(sp.elements) <= sp.limit,
min (sp.elements) >= 0.
constraint sp.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
27 July 2016
University of Virginia CS 655
19
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)
27 July 2016
University of Virginia CS 655
20
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(size) = card
27 July 2016
R(choose) = get
R(equal) = equal
University of Virginia CS 655
21
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
27 July 2016
University of Virginia CS 655
22
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 precondition, so it is not a subtype.
27 July 2016
University of Virginia CS 655
23
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);
27 July 2016
University of Virginia CS 655
24
uset  bag?
• A:ST
• A : Set  BBag
8
 s : Set; A (s) = < s, >
• Renaming:
– R(insert) = put
– R(size) = card
R(choose) = get
R(equal) = equal
• Check method choose  get (same as
bset)
27 July 2016
University of Virginia CS 655
25
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
27 July 2016
University of Virginia CS 655
26
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!
27 July 2016
University of Virginia CS 655
27
Summary Questions
• uset  bset?, bset  uset?
• Does the Liskov/Wing subtype relation
definition match intuition?
• Is it useful?
27 July 2016
University of Virginia CS 655
28
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++
27 July 2016
University of Virginia CS 655
29