cs784(Prasad)

1. Specification and Implementation of Abstract Data Types cs784(Prasad) 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 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

4. Specification of Data Types Type : Values + Operations Specify SyntaxSemantics Signature of Ops Meaning of Ops Model-basedAlgebraic Axioms Description in terms of Give axioms defining standard “primitive” data types the operations cs784(Prasad) 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 atoma: a :  S-expr cs784(Prasad) 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

7. Expectations of + : N x N  N • A Few Examples • 1 + 2 = 3 • zero + succ(succ(zero)) = succ(succ(zero)) • x + 0 = x • Relating to Other Operators • 2 * (3 + 4) = 2 * 7 = 14 = 6 + 8 • x * ( y + z) = x * y + x * z cs784(Prasad) 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

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 cs784(Prasad) L34ADT 10

11. Classification of Operations • Constructors • Generating values in the type • E.g., nil, cons, atoms a in ADTS-expr • Every value ought to be “constructible” • Non-constructors • E.g., car, cdr in ADTS-expr • Observers • Extract a value outside the type • E.g., null in ADTS-expr • Constructors: As few as possible cs784(Prasad) L34ADT 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? 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 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

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

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

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 = Kithen I else lookUp(K,T)(“last update overrides the others”) • Note: Delete is missing. cs784(Prasad) 18

19. Table Examples • Constructions • 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

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

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

23. A-list in LISP • for all L in A-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

24. Natural Numbers 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

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)) cs784(Prasad) 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

27. A-list Revisted a :  A 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

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

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. ==vsequals in Java cs784(Prasad) 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

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 inst) then size(st) • else 1 + size(st) • E.g., size({2,2,2}) = size({2,2}) = size ({2}) = 1

39. OL: Ordered (N) Lists • Intuitively, • 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

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)) cs784(Prasad) 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

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

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

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