specification and implementation of abstract data types
Skip this Video
Download Presentation
Specification and Implementation of Abstract Data Types

Loading in 2 Seconds...

play fullscreen
1 / 49

Specification and Implementation of Abstract Data Types - PowerPoint PPT Presentation

  • Uploaded on

Specification and Implementation of Abstract Data Types. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Specification and Implementation of Abstract Data Types' - Patman

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
data abstraction
Data Abstraction
  • Clients
    • Interestedin 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.


specification of data types
Specification of Data Types

Type : Values + Operations



Signature of Ops Meaning of Ops


Description in terms of Give axioms satisfied

standard “primitive” data types by the operations


syntax of lisp s expr
Syntax of LISP S-expr
  • operations: nil, cons, car, cdr, null
  • signatures:

nil: S-expr

cons: S-expr*S-expr-> S-expr

car: S-expr-> S-expr

cdr: S-expr-> S-expr

null: S-expr-> boolean

for every atoma:

a : S-expr


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




  • Illegal





semantics of what to expect
Semantics of +: What to expect?

+ : NxN->N

1 + 2 = 3

zero + succ(succ(zero)) = succ(succ(zero))

x + 0 = x

2 * (3 + 4) = 2 * 7 = 14 = 6 + 8

x * ( y + z) = y * x + x * z


semantics of s expr what to expect
Semantics of S-Expr : What to expect?

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


formal spec of adts
Formal Spec. of ADTs

Characteristics of an “Adequate” Specification

  • Completeness (No “undefinedness”)
  • Consistency/Soundness (No conflicting definitions)
    • Minimality


Learn to write sound and complete algebraic(axiomatic) specifications of ADTs


classification of operations
Classification of Operations
  • Observers
    • generate a value outside the type
      • E.g., null in ADTS-expr
  • Constructors
    • required for representing values in the type
      • E.g., nil, cons, atoms a in ADTS-expr
  • Non-constructors
    • remaining operations
      • E.g., car, cdr in ADTS-expr


s expr in lisp
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


algebraic spec
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(a) = ?error? cdr(cons(S,T)) = T

car(nil) = ?error? car(a) = ?error? car(cons(S,T)) = S

null(nil) = true null(a) = false

null(cons(S,T)) = false

  • Omitting the equation for “nil” implies that implementations that differ in the interpretation of “nil” are all equally acceptable.


s expr s
  • car(a)
  • cons(a,nil)
  • car(cons(a,nil)) =
  • a
  • cons( car(cons(a,nil)), cdr(cons(a,a)) ) =
  • cons( a , a )


motivation for classification minimality
Motivation for Classification : Minimality
  • 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)) = ...


adt table symbol table directory
ADT Table (symbol table/directory)

empty : Table

update : Key x Info x Table ->Table

lookUp: Key x Table -> Info

lookUp(K,empty) = error

lookUp(K,update(Ki, I, T)) =

if K = Ki then I else lookUp(K,T)

(“last update overrides the others”)


table s
  • empty
  • update(5, “abc”, empty)
  • update(10, “xyz”, update(5, “abc”, empty))
  • update(5, “xyz”, update(5, “abc”, empty))


  • lookup (5,update(5, “xyz”, update(5, “abc”, empty)) )
  • lookup (5,update(5, “xyz”, update(5, “xyz”, empty)) )
  • lookup (5,update(5, “xyz”, empty) )
  • “xyz”


    • Array-based
    • Linear List - based
    • Tree - based
      • Binary Search Trees, AVL Trees, B-Trees etc
    • Hash Table - based
  • These exhibit a common Table behavior, but differ in performance aspects (search time).
  • Correctness of a program is assured even when the implementation is changed as long as the spec is satisfied.


cont d
  • Accounts for various other differences (Data Invariants) in implementation such as
    • 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).


a list in lisp
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


for all L in A-list

cdr(cons(a,L)) = L

car(cons(a,L)) = a

null(nil) = true

null(cons(a,L)) = false

  • Consciously silent about nil-list.


natural numbers
Natural Numbers

zero : N

succ : N-> N

add : NxN-> N

iszero : N->boolean

observers : iszero

constructors : zero, succ

non-constructors : add

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


for all I,J in N

add(I,J) = ?

add(zero,I) = I

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

iszero(I) = ?

iszero(zero) = true

iszero(succ(I)) = false


cont d23

add(succ(succ(zero)), succ(zero))

= succ(succ(succ(zero)))

  • The first rule eliminates add from an expression, while the second rule simplifies the first argument to add.
  • Associativity, commutativity, and identity properties of add can be deduced from this definition through purely mechanical means.


a list revisted
A-list Revisted

a : A

nil : A-list

list : A -> A-list

append : A-list x A-list -> A-list

null : A-list -> boolean

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


algebraic spec25
Algebraic Spec
  • constructors
    • nil, list, append
  • observer

isnull(nil) = true

isnull(list(a)) = false

isnull(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) = L

append(nil,L) = L

    • Associativity Rule



append(L1, append(L2,L3))


intuitive understanding of constructors
Intuitive understanding of constructors
  • The constructor patterns 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 patterns. Specifically, constructor axioms correspond to computations necessary for equality checking and aid in defining a normal form.
      • Cf. ==vsequal in Java


writing adt specs
Writing ADT Specs
  • Idea: Specify “sufficient” axioms such that syntactically distinct terms (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 historyofconstruction of the value.


general strategy for adt specs
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.


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


declarative specification
Declarative Specification
  • Let *: N x N -> N denote integer multiplication.

Equation: n * n = n

Solution: n = 0 \/ n = 1.

  • Let f: N x N -> N denote a binary integer function.

Equation: 0 f 0 = 0

Solution: f = “multiplication” \/

f = “addition” \/ f = “subtraction” \/ ...


delete set
delete : Set
  • for all n, m inN, s inSet

delete(n,empty) = empty

delete(n,insert(m,s)) =

if (n=m)

then delete(n,s) (invalid: s)

else insert(m,delete(n,s))

delete(5, insert(5,insert(5,empty)) ) {5,5}

== empty {}

=/= insert(5,empty)





delete list
delete : List
  • Previous axioms capture “remove all occurrences” semantics.
  • For “remove last occurrence” semantics:

for all n, m inN, s inList

delete(n,empty) = empty

delete(n,insert(m,s)) =

if (n=m) then s

else insert(m,delete(n,s))

delete(5, insert(5,insert(5,empty)) ) [5,5]

== insert(5,empty) [5]


delete list34
delete : List
  • Previous axioms capture “remove all / last occurrences” semantics.
  • For “remove first occurrence” semantics:

for all n, m inN, s inList

delete(n,empty) = empty

delete(n,insert(m,s)) =

if (n=m) andnot (n in s) then s

else insert(m,delete(n,s))

delete(1, insert(1,insert(2,insert(1,insert(5,empty)))) ) [5,1,2,1]

== insert(1,insert(2,insert(5,empty)))[5,2,1]


size list vs set
size: List vs Set
  • size(insert(m,l)) = 1 + size(l)
    • E.g., size([2,2,2]) = 1 + size([2,2])
  • size(insert(m,s)) =

if (m ins) then size(s)

else 1 + size(s)

    • E.g., size({2,2,2}) = size({2,2})

= size ({2}) = 1


model based vs algebraic
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.


axiomatization algebraic structures
Axiomatization: Algebraic Structures
  • A set G with operation * forms a group if
      • Closure: a,b eG implies a*b eG.
      • Associativity: a,b,c eG implies a*(b *c) = (a*b)*c.
      • Identity: There exists i eG such that

i*a = a*i = a for all a eG.

      • Inverses: For every a eG there exists an element

~a eG such that a * ~a = ~a * a = i.

  • Examples:
      • (Integers, +), but not (N, +)
      • (Reals - {0}, *), but not (Integers, *)
      • (Permutation functions, Function composition)



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


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


cont d40
  • 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 represent the function?
      • How to carry out the call?


cont d41
  • ADT spec. are absolutely necessary to automate formal reasoning about programs. Theorem provers such as Boyer-Moore prover (NQTHM), LARCH, PVS, HOL, etc routinely use such axiomatization of types.
  • Provides a theory of equivalence of values that enables design of a suitable canonical form.
      • Identity-> delete
      • Associativity-> remove parenthesis
      • Commutativity-> sort


spec vs impl
Spec vs Impl

The reason to focus on the behavioral aspects, ignoring

efficiency details initially, is that the notion of a “best implementation” requires application specific issues and trade-offs. In other words, the distribution of work among

the various operations is based on a chosen representation,

which in turn, is dictated by the pragmatics of an application. However, in each potential implementation, there is always some operations that will be efficient while others will pay the price for this comfort.


ordered integer lists
Ordered Integer Lists

null : oil->boolean

nil : oil

hd : oil->int

tl : oil->oil

ins : int x oil->oil

order : int_list->oil

Constructors: nil, ins

Non-constructors: tl, order

Observers: null, hd


    • 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.
      • It is not the case that for all I in int, L in oil,

hd(ins(I,L)) = I.

      • This holds iff I is the minimum in ins(I,L).
    • Similarly for tl.


axioms for constructors
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 constructors
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))


axioms for observers
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


scheme implementation
Scheme Implementation

(define nullnull?)

(define nil’())

(define inscons)

(define (hd ol) *min* )

(define (tl ol) *list sans min* )

(define (order lis) *sorted list* )


possible implementations
Possible Implementations
  • Representation Choice 1:
    • List of integers with duplicates
      • ins is cons but 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