1. Specification and Implementation of Abstract Data Types
cs784(Prasad) 1 1

2. Spec v. Impl
(Functional) Specs should describe behavioral aspects only
Should ignore performance details
A “suitable implementation” requires client specific issues and trade-offs.
Even when you “can read” a suggested implementation from an Algebraic Spec, do not.
Distribution of work among the various operations is based on a chosen representation, which in turn is dictated by the pragmatics of an application.
In different implementations, some operations will be efficient while others won’t.

3. Data Abstraction Clients Implementors
Need to know WHAT functions/services a module provides,
Not (should not be) HOW they are carried out.
So, ignore details irrelevant to the overall behavior, for clarity.
Implementors
May change the HOW (code), to improve performance, …
So, ensure that clients do not make unwarranted assumptions.
cs784(Prasad)
L34ADT 3 3

4. Specification of Data Types
Type : Values + Operations
Specify
Syntax Semantics
Signature of Ops Meaning of Ops
Model-based Algebraic Axioms
Description in terms of Give axioms defining
standard “primitive” data types the operations
cs784(Prasad) 4 4

5. Signatures of LISP S-expr Ops
nil:  S-expr
cons: S-expr x S-expr   S-expr
car: S-expr   S-expr
cdr: S-expr   S-expr
null: S-expr  boolean
for every atom a:
a :  S-expr
cs784(Prasad) 5 5

6. Signatures of LISP S-expr Ops
Signature tells us how to form complex terms from primitive operations.
Legal
nil
null(cons(nil,nil))
cons(car(nil),nil)
Illegal
nil(cons)
null(null)
cons(nil)
cs784(Prasad)
L34ADT 6 6

7. Expectations of + : N x N  N
A Few Examples
= 3
zero + succ(succ(zero)) = succ(succ(zero))
x = x
Relating to Other Operators
2 * (3 + 4) = 2 * 7 = =
x * ( y + z) = x * y + x * z
cs784(Prasad) 7 7

8. What to expect of S-Expr ?
Examples
null(nil) = true
car(cons(nil,nil)) = nil
null(cdr(cons(nil,cons(nil,nil)))) = false
for all E,F in S-Expr
car(cons(E,F)) = E
null(cons(E,F)) = false
cs784(Prasad) 8 8

9. Algebraic Specs of ADT Operations on ADT
Constructors
Others
Axioms: True statements about the ADT
Algebraic Equational Axioms: LHS = RHS
LHS: Application of Operations
RHS:
similar to LHS, but
may also include if-expressions
cs784(Prasad/pm) 9

10. Algebraic Specs of ADTs
Characteristics of an “Adequate” Specification
Completeness (No “undefinedness”)
Consistency/Soundness (No conflicting definitions)
GOAL:
Learn to write sound and complete algebraic specifications of ADTs
If a function itself is partial, we may use preconditions to express that fact.
For example, “/” operation on N when the denominator is 0. In the spec,
specify that denominator be non-zero.
Similarly, car and cdr on empty lists.
(Cf. exceptions)
cs784(Prasad)
L34ADT 10 10

11. Classification of Operations
Constructors
Generating values in the type
E.g., nil, cons, atoms a in ADT S-expr
Every value ought to be “constructible”
Non-constructors
E.g., car, cdr in ADT S-expr
Observers
Extract a value outside the type
E.g., null in ADT S-expr
Constructors: As few as possible
cs784(Prasad)
L34ADT 11 11

12. Stack ADT Operations createStack: → Stack
push: Stack x element → Stack
pop: Stack → Stack, element
top: Stack → element
isEmpty: Stack → boolean
error an Element?
Some authors define pop: Stack → Stack, element as pop: Stack → Stack without the element.
cs784(pm) 12

13. Stack ADT Axioms isEmpty(createStack()) = true
isEmpty(push(s, x)) = false
top(createStack()) = error
top(push(s, x)) = x
pop(createStack()) = error
pop(push(s, x)) = (s, x)
cs784(pm) 13

14. S-Expr in LISP Observers : null Constructors : a, nil, cons
a : → S-Expr
nil : → S-Expr
cons : S-Expr x S-Expr → S-Expr
car : S-Expr → S-Expr
cdr : S-Expr → S-Expr
null : S-Expr → boolean
Observers : null
Constructors : a, nil, cons
Non-constructors : car, cdr
cs784(Prasad)
L34ADT 14 14

15. Algebraic Spec
Write equational axioms that characterize the meaning of all the operations.
Describe the meaning of the observers and the non-constructors on all possible constructor expressions.
Note the use of typed variables to abbreviate the definition. (“Finite Spec.”)
cs784(Prasad)
L34ADT 15 15

16. Algebraic Spec of S-expr
cdr(nil) = error cdr(a) = error
car(nil) = error car(a) = error
null(nil) = true null(a) = false
for all S, T in S-expr
null(cons(S,T)) = false
car(cons(S,T)) = S
cdr(cons(S,T)) = T
Omitting other equations for “nil” implies that implementations that differ only in the interpretation of “nil” are acceptable.

17. Motivation for Minimal Constructors
If car and cdr are also regarded as constructors (as they generate values in the type), then the spec. must consider other cases to guarantee completeness (or provide sufficient justification for their omission).
for all S in S-expr:
null(car(S)) = ...
null(cdr(S)) = ...
cs784(Prasad)
L34ADT 17 17

18. ADT Table (aka symbol table/directory)
Signatures
empty:  Table
update: Key × Info x Table Table
lookUp: Key × Table nfo
Equations
lookUp(K, empty) = error
lookUp(K, update(Ki, I, T)) = if K = Ki then I else lookUp(K,T) (“last update overrides the others”)
Note: Delete is missing.
cs784(Prasad) 18 18

19. Table Examples Constructions Answer: “xyz” empty
update(5, “abc”, empty)
update(10, “xyz”, update(5, “abc”, empty))
update(5, “xyz”, update(5, “abc”, empty))
Lookup Operations (Search )
lookup (5, update(5, “xyz”, update(5, “abc”, empty)) )
lookup (5, update(5, “xyz”, update(5, “xyz”, empty)) )
lookup (5, update(5, “xyz”, empty) )
Answer: “xyz”
cs784(Prasad/pm) 19 19

20. Implementations of Table
“Different” implementations obeying the Algebraic Specs of Table.
Array-based
Linear List- based
Tree- based
Binary Search Trees, AVL Trees, B-Trees, etc.
Hash Table- based
Semantics of a client program is unchanged even when an implementation is replaced with another from the above.

21. Implementations of Table(cont’d)
Differ in performance aspects
search time
memory usage.
Other possible differences
Eliminating duplicates.
Retaining only the final binding.
Maintaining the records sorted on the key.
Maintaining the records sorted in terms of the frequency of use (a la caching).
cs784(Prasad)
L34ADT 21 21

22. A-list in LISP a :  A nil :  A-list cons : A x A-list A-list
car : A-list A
cdr : A-list A-list
null : A-list boolean
Observers : null, car
Constructors : nil, cons
Non-constructors : cdr
cs784(Prasad) 22 22

23. A-list in LISP for all L in A-list Mostly silent about nil-list.
cdr(cons(a,L)) = L
car(cons(a,L)) = a
null(nil) = true
null(cons(a,L)) = false
Mostly silent about nil-list.
cs784(Prasad)
L34ADT 23 23

24. Natural Numbers observers : iszero constructors : zero, succ
add :  x  
iszero :   boolean
observers : iszero
constructors : zero, succ
non-constructors : add
Each number has a unique representation in terms of its constructors.
cs784(Prasad) 24 24

25. Natural Numbers Axioms
iszero(zero) = true
iszero(succ(n)) = false
for all I,J in 
add(zero, I) = I
add(succ(J), I) = succ(add(J,I))
iszero(x) = (x = zero)
cs784(Prasad) 25 25

26. Natural Numbers (cont’d)
add(succ(succ(zero)), succ(zero))
= succ(succ(succ(zero)))
The 4-th rule eliminates add from an expression, while the 5-th rule simplifies the first argument to add.
Associativity, commutativity, and identity properties of add can be deduced from this definition through deduction.
cs784(Prasad/pm) 26 26

27. A-list Revisted a :  A Without cons/car/cdr Example values
nil :  A-list
list : A A-list
append : A-list x A-list A-list
isnull : A-list boolean
Without cons/car/cdr
Example values
nil, list(a), append(nil, list(a)), ...
cs784(Prasad) 27 27

28. Algebraic Spec of A-list
constructors
nil, list, append
observer
isnull(nil) = true
isnull(list(a)) = false
isnull(append(L1, L2)) =
isnull(L1) /\ isnull(L2)
cs784(Prasad)
L34ADT 28 28

29. A-list specification contd.
Problem : A value has multiple constructions.
Solution : Add axioms for constructors.
Identity Rule
append(L, nil) = L
append(nil, L) = L
Associativity Rule
append(append(L1, L2), L3) =
append(L1, append(L2, L3))

30. Intuitive understanding of constructors
The constructor expressions correspond to distinct memory/data patterns required to store/represent values in the type.
The constructor axioms can be viewed operationally as rewrite rules to simplify constructor expressions. Specifically, constructor axioms correspond to computations necessary for equality checking and aid in defining a normal form.
Cf. == vs equals in Java
cs784(Prasad) 30 30

31. General Strategy for ADT Specs
Constructors
Every value expected to be in the ADT must be constructible.
Non-constructors
Provide axioms to collapse a non-constructor term into a term involving only constructors.
Observers
Define the meaning of an observer on all constructor terms, checking for consistency.
Syntax
Specify signatures and classify operations.

32. Strategy for ADT Specs (contd)
Completeness
Define non-constructors and observers on all possible constructor patterns
Consistency
Check for conflicting reductions
Implementation of a type
An interpretation of the operations of the ADT that satisfies all the axioms.

33. Multiple Constructions for a Value
Write axioms to ensure that two constructor terms that represent the same value can be proven so.
E.g., identity, associativity, commutativity rules.

34. Declarative Specifications
Declare the desired item (using equations) by describing what properties it should have.
Did we define it “correctly”?
Can we determine what the defined item is?
A Famous Example
M(n) = if n > 100 then n – 10 else M(M(n+11)) fi
McCarthy 91 function; M(n) = 91 for n ≤ 101,  = n − 10 for n > 101.

35. Decl Spec Examples Let : N x N  N denote an infix binary function
Equation: n  n = n
Solution: n = 0 \/ n = 1.
 = “multiplication”
Equation: n  n = 0
Solutions: n = 0
 = “multiplication”,
 = “addition”,
 = “subtraction”, …

36. delete: Set  Set for all n, m in N, s in Set
delete(n, empty) = empty
delete(n, insert(m, s)) =
if (n = m)
then delete(n, s)
else insert(m, delete(n, s))
Example: delete(5, insert(5, insert(5,empty)) )
= empty
/= insert(5,empty)
Definitions along these lines for Tables capture “remove all occurrences” semantics.

37. delete: List  List “remove last occurrence” semantics
(For now imagine that “insert” is like prepend)
for all n, m in N, s in List
delete(n, empty) = empty
delete(n, insert(m, s)) =
if (n = m)
then s
else insert(m, delete(n, s))
Example: delete(5, insert(5,insert(5,empty)) ) = insert(5,empty)
“remove first/any/… occurrence” semantics is possible.
Questions: “first” and “last” based on what? Chronology? List representation? Is “insert” like prepend or append or something else?

38. size:List  N v. size:Set  N
size(insert(m, lst)) = 1 + size(lst)
E.g., size([2,2,2]) = 1 + size([2,2])
size(insert(m, st)) =
if (m in st) then size(st)
else size(st)
E.g., size({2,2,2}) = size({2,2}) = size ({2}) = 1

39. OL: Ordered (N) Lists Intuitively, Constructors: Non-constructors:
numbers in the list are ordered, and
no duplicates.
Constructors:
nil :  OL
ins : N x OL  OL
Non-constructors:
tl : OL  OL
order : N_list  OL
Observers:
null : OL  boolean
hd : OL  N

40. Expectations of OL
syntactically different, but semantically equivalent, constructor expressions
ins(2,ins(5,nil)) = ins(5,ins(2,nil))
ins(2, ins(2, nil)) = ins(2, nil)
hd should return the smallest element.
May have no relation to the order of insertion.
Similarly for tl.
cs784(Prasad/pm) 40 40

41. OL Axioms for Constructors
L is an ordered integer list; i, j in N
null(nil) = true
null(ins(I, L)) = false
Idempotence: ins(i, ins(i,L)) = ins(i,L)
Commutativity: ins(i, ins(j, L)) = ins(j, ins(j, L))
Ref Knuth’s book
cs784(Prasad) 41 41

42. OL Axioms for Non-constructors
tl(nil) = error
tl(ins(I,L)) =
tl(ins(I, nil)) = nil
tl(ins(I, ins(J,L))) =
I < J => ins(J, tl(ins(I,L)) )
I > J => ins(I, tl(ins(J,L)) )
I = J => tl( ins(I, L))
(cf. constructor axioms for duplicate elimination)
order(nil) = nil
order(cons(I, L)) = ins(I, order(L))
cs784(Prasad) 42 42

43. OL Axioms for Observers
hd(nil) = error
hd(ins(I, nil)) = I
hd(ins(I,ins(J, L))) =
I < J => hd( ins(I, L) )
I > J => hd( ins(J, L) )
I = J => hd( ins(I, L) )
null(nil) = true
null(ins(I, L)) = false
cs784(Prasad) 43 43

44. Ordered List: Implementations
Representation Choice 1:
List of integers with duplicates
ins can be cons but then hd and tl require linear- time search
Representation Choice 2:
Sorted list of integers without duplicates
ins requires search but hd and tl can be made more efficient
Representation Choice 3:
Balanced-tree : Heap
cs784(Prasad/pm) 44

45. Summary of ADT spec
Least common “denominator” of all possible implementations.
Focus on the essential behavior.
An implementation is a refinement of ADT spec.
IMPL = ADT + Representation “impurities”
To prove equivalence of two implementations, show that they satisfy the same ADT spec.
In the context of OOP, a class implements an ADT, and the spec. is a class invariant.

46. Advantages of ADT specs
Indirectly, ADT spec. gives us the ability to vary or substitute an implementation.
E.g., In the context of interpreter/compiler, a function definition and the corresponding calls (ADT FuncValues) together must achieve a fixed goal. However, there is freedom in the precise apportioning of workload between the two separate tasks:
How to implement/represent the function?
How to carry out the call?
cs784(Prasad)
L34ADT 46 46

47. Equality of Entities Two viewpoints: v1 and v2 are equal, when
they can be proven to be equal
they cannot be proven that they are unequal
When a value can be multiply constructed, one of these constructions can be defined as a canonical form

48. Applications of ADT specs
ADT spec. are useful in automated formal reasoning about programs.
Provides a theory of equivalence of values that enables design of a suitable canonical form.
Identity  delete
Associativity  remove parenthesis
Commutativity sort
cs784(Prasad/pm) 48 48