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

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.

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

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

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

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

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 7

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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”, …

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.

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?

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

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

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

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

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

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

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

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.

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

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

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