Specification and Implementation of Abstract Data Types

ceg860 (Prasad) LADT 1

Specification and Implementation of Abstract Data Types

Algebraic Techniques


Data Abstraction• Clients

– Interested in WHAT services a module provides, not HOW they are carried out. So, ignore details irrelevant to the overall behavior, for clarity.

• Implementors– Reserve the right to change the code, to

improve performance. So, ensure that clients do not make unwarranted assumptions.


Abstraction : Equivalence Relations– Computability

• Recursive vs Non-recursive– Semantics

• Behavioral Equivalence– Resource-independent interchangeability

• Performance aspect irrelevant for “correctness”– E.g., Groups, Fields, Sorting, UNIX, etc

– Algorithms• Time and Space requirements

– Big-Oh (Worst-case Analysis)– NP-hard vs Polynomial-time


Specification of Data Types Type : Values + Operations Specify Syntax Semantics Signature of Ops Meaning of Ops

Model-based Axiomatic(Algebraic) Description in terms of Give axioms satisfied standard “primitive” data types by the operations


Syntax of LISP S-expr

• operations: nil, cons, car, cdr, null• signatures:

nil: S-exprcons: S-expr S-expr S-expr car: S-expr S-exprcdr: S-expr S-exprnull: S-expr boolean

for every atom a: a : S-expr


• Signature tells us how to form complex terms from primitive operations.

• Legalnilnull(cons(nil,nil))cons(car(nil),nil)

• Illegalnil(cons)null(null)cons(nil)


Formal Spec. of ADTsCharacteristics of an “Adequate” Specification

– Completeness (No undefinedness)– Consistency/Soundness (No conflicting definitions)

GOAL: Learn to write sound and complete

algebraic(axiomatic) specifications of ADTs


Classification of Operations• Observers (“Queries”)

– generate a value outside the type• E.g., null in ADT S-expr

• Constructors (“Creators and Commands”)– required for representing values in the type

• E.g., nil, cons, atoms a in ADT S-expr

• Non-constructors (“Creators and Commands”)– remaining operations

• E.g., car, cdr in ADT S-expr


ADT Table (symbol table/directory)empty : Tableupdate : Key x Info x Table TablelookUp: Key x Table nfo

lookUp(K,empty) = error(Use of variable)(Alternative : Use of Preconditions)lookUp(K,update(Ki, I, T)) = if K = Ki then I else lookUp(K,T)(“last update overrides the others”)


Implementations– Array-based– LinearList-based– Tree-based

• Binary Search Trees, AVL Trees, B-Trees etc– HashTable-based

• These exhibit a common Table behavior, but differ in performance aspects.

• Correctness of a client program is assured even when the implementation is changed.


A-list in LISP a : A

nil : A-listcons : A x A-list A-listcar : A-list A cdr : A-list A-listnull : A-list boolean

• Observers : null, car• Constructors : nil, cons• Non-constructors : cdr


Algebraic Spec

• Write axioms (equations) that characterize the meaning of all the operations.

• Describe the meaning of the observers and the non-constructors on all possible constructor patterns.

• Note the use of typed variables to abbreviate the definition. (“Finite Spec.”)


• for all S, T in S-expr cdr(nil) = error cdr(cons(S,T)) = T car(nil) = error car(cons(S,T)) = S null(nil) = true null(cons(S,T)) = false

(To avoid “error”, use preconditions instead.)

• Other atoms “a” are handled in the same way as “nil”.


Natural Numberszero : succ : add : x iszero : boolean

observers : iszeroconstructors : zero, succnon-constructors : add

Each numbers has a unique representation in terms of its constructors.


for all I,J in

add(zero,I) = Iadd(succ(J), I) = succ(add(J,I))

iszero(zero) = trueiszero(succ(n)) = false


A-list Revisted a : A

nil : A-listlist : A A-listappend : A-list x A-list A-listnull : A-list boolean

• values – nil, list(a), append(nil, list(a)), ...


Algebraic Spec

• constructors– nil, list, append

• observerisnull(nil) = trueisnull(list(a)) = falseisnull(append(L1,L2)) = isnull(L1) /\ isnull(L2)


• Problem : Same value has multiple representation in terms of constructors.

• Solution : Add axioms for constructors.– Identity Rule

append(L,nil) = Lappend(nil,L) = L

– Associativity Rule append(append(L1,L2),L3) = append(L1, append(L2,L3))


Writing ADT Specs• Idea: Specify “sufficient” axioms such that

syntactically distinct patterns that denote the same value can be proven so.– Completeness

• Define non-constructors and observers on all possible constructor patterns

– Consistency• Check for conflicting reductions

• Note: A term essentially records the detailed history of construction of the value.


General Strategy for ADT Specs

• Syntax– Specify signatures and classify operations.

• Constructors– Write axioms to ensure that two constructor

terms that represent the same value can be proven so.

• E.g., identity, associativity, commutativity rules.


• 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.

Implementation of a type An interpretation of the operations of the ADT

that satisfies all the axioms.


Model-based vs Algebraic

• A model-based specification of a type satisfies the corresponding axiomatic specification. Hence, algebraic spec. is “more abstract” than the model-based spec.

• Algebraic spec captures the least common-denominator (behavior) of all possible implementations.


Example car( cons( X, Y) ) = X cdr( cons (X, Y) ) = Y

(define (cons x y) (lambda (m) (cond ((eq? m ’first) x) (eq? m ’second) y) ))) ; “closure”(define (car z) (z ’first))(define (cdr z) (z ’second))


Canonical Form for Equality Testing

• Identity Element

• Associative Op

• Commutative Op

• Idempotent

• Delete element

• Collapse tree into linear list (parenthesis redundant)

• Order list elements

• Remove duplicates


Ordered Integer Listsnull : oil booleannil : oil hd : oil inttl : oil oilins : int x oil oilorder : int_list oil

Constructors: nil, insNon-constructors: tl, orderObservers: null, hd


• Problem: – syntactically different, but semantically equivalent

constructor terms

ins(2,ins(5,nil)) = ins(5,ins(2,nil))ins(2,ins(2,nil)) = ins(2,nil)

– hd should return the smallest element.• for all I in int, L in oil, it is not the case that

hd(ins(I,L)) = I. • This holds iff I is the minimum in ins(I,L).

– Similarly for tl.


Axioms for Constructors• Idempotence

– for all ordered integer lists L; for all I in int ins(I, ins(I,L)) = ins(I,L)

• Commutativity– for all ordered integer lists L; for all I, J in int

ins(I, ins(J,L)) = ins(J, ins(I,L))

Completeness : Any permutation can be generated by exchanging adjacent elements.


Axioms for Non-constructorstl(nil) = errortl(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) = nilorder(cons(I,L)) = ins(I,order(L))


Axioms for Observershd(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) = truenull(cons(I,L)) = false


Object-Oriented Software Construction

• Building software systems as structured collections of (possibly partial) abstract data type implementations.

• Function categories– Creators ( …x … – Queries (…x T x … …)– Commands (…x T x …

Specification and Implementation of Abstract Data Types

Documents