Specification and Implementation of Abstract Data Types

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

3
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

4
Syntax of LISP S-expr

• operations nil, cons, car, cdr, null
• signatures
• nil S-expr
• cons S-expr S-expr -gt S-expr
• car S-expr -gt S-expr
• cdr S-expr -gt S-expr
• null S-expr -gt boolean
• for every atom a
• a S-expr

5

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

6
Semantics of What to expect?

• N x N -gt 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

7
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

8
Formal Spec. of ADTs

• Characteristics of an Adequate Specification
• Completeness (No undefinedness)
• Consistency/Soundness (No conflicting
  definitions)
• Minimality
• GOAL
• Learn to write sound and complete
  algebraic(axiomatic) specifications of ADTs

9
Classification of Operations

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

10
S-Expr in LISP

• a S-Expr
• nil S-Expr
• cons S-Expr x S-Expr -gt S-Expr
• car S-Expr -gt S-Expr
• cdr S-Expr -gt S-Expr
• null S-Expr -gt boolean
• Observers null
• Constructors a, nil, cons
• Non-constructors car, cdr

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

12

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

13
S-Exprs

• car(a)
• cons(a,nil)
• car(cons(a,nil))
  
• a
• cons( car(cons(a,nil)), cdr(cons(a,a)) )
• cons( a , a
  )

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

15
ADT Table (symbol table/directory)

• empty Table
• update Key x Info x Table -gt Table
• lookUp Key x Table -gt 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)

16
Tables

• empty
• update(5, abc, empty)
• update(10, xyz, update(5, abc, empty))
• update(5, xyz, update(5, abc, empty))
• (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) )
• xyz

17
Implementations

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

18
(contd)

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

19
A-list in LISP

• a A
• nil A-list
• cons A x A-list -gt A-list
• car A-list -gt A
• cdr A-list -gt A-list
• null A-list -gt boolean
• Observers null, car
• Constructors nil, cons
• Non-constructors cdr

20

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

21
Natural Numbers

• zero N
• succ N -gt N
• add N x N -gt N
• iszero N -gt boolean
• observers iszero
• constructors zero, succ
• non-constructors add
• Each number has a unique representation in terms
  of its constructors.

22

• 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

23
(contd)

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

24
A-list Revisted

• a A
• nil A-list
• list A -gt A-list
• append A-list x A-list -gt A-list
• null A-list -gt boolean
• values
• nil, list(a), append(nil, list(a)), ...

25
Algebraic Spec

• constructors
• nil, list, append
• observer
• isnull(nil) true
• isnull(list(a)) false
• isnull(append(L1,L2))
• isnull(L1) /\
  isnull(L2)

26

• 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(append(L1,L2),L3)
• append(L1, append(L2,L3))

27
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. vs equal in Java

28
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
  history of construction of the value.

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

30

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

31
Declarative Specification

• Let N x N -gt N denote integer
  multiplication.
• Equation n n n
• Solution n 0 \/ n 1.
• Let f N x N -gt N denote a binary integer
  function.
• Equation 0 f 0 0
• Solution f multiplication
  \/
• f addition \/ f subtraction \/
  ...

32
delete Set

• for all n, m in N, s in Set
• delete(n,empty) empty
• delete(n,insert(m,s))
• if (nm)
• 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)

5,5

5
33
delete List

• Previous axioms capture remove all occurrences
  semantics.
• For remove last occurrence semantics
• for all n, m in N, s in List
• delete(n,empty) empty
• delete(n,insert(m,s))
• if (nm) then s
• else insert(m,delete(n,s))
• delete(5, insert(5,insert(5,empty)) )
  5,5
• insert(5,empty)
  5

34
delete List

• Previous axioms capture remove all / last
  occurrences semantics.
• For remove first occurrence semantics
• for all n, m in N, s in List
• delete(n,empty) empty
• delete(n,insert(m,s))
• if (nm) and not (n in s) then s
• else insert(m,delete(n,s))
• delete(1, insert(1,insert(2,insert(1,insert(5,empt
  y)))) ) 5,1,2,1
• insert(1,insert(2,insert(5,empty)))
  5,2,1

35
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 in s) then size(s)
• else 1 size(s)
• E.g., size(2,2,2) size(2,2)
• size (2) 1

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

37
Axiomatization Algebraic Structures

• A set G with operation forms a group if
• Closure a,b e G implies ab e G.
• Associativity a,b,c e G implies a(b c)
  (ab)c.
• Identity There exists i e G such that
• ia ai a for all a
  e G.
• Inverses For every a e G there exists an
  element
• a e G such that a a
  a a i.
• Examples
• (Integers, ), but not (N, )
• (Reals - 0, ), but not (Integers, )
• (Permutation functions, Function composition)

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

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

40
(Contd)

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

41
(Contd)

• 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 -gt delete
• Associativity -gt remove parenthesis
• Commutativity -gt sort

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

43
Ordered Integer Lists

• null oil -gt boolean
• nil oil
• hd oil -gt int
• tl oil -gt oil
• ins int x oil -gt oil
• order int_list -gt oil
• Constructors nil, ins
• Non-constructors tl, order
• Observers null, hd

44

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

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

46
Axioms for Non-constructors

• tl(nil) error
• tl(ins(I,L)) ?
• tl(ins(I,nil)) nil
• tl(ins(I,ins(J,L)))
• I lt J gt ins( J, tl(ins(I,L)) )
• I gt J gt ins( I, tl(ins(J,L)) )
• I J gt tl( ins( I,L ) )
• (cf. constructor axioms for duplicate
  elimination)
• order(nil) nil
• order(cons(I,L)) ins(I,order(L))

47
Axioms for Observers

• hd(nil) error
• hd(ins(I,nil)) I
• hd(ins(I,ins(J,L)))
• I lt J gt hd( ins(I,L) )
• I gt J gt hd( ins(J,L) )
• I J gt hd( ins(I,L) )
• null(nil) true
• null(ins(I,L)) false

48
Scheme Implementation

• (define null null?)
• (define nil ())
• (define ins cons)
• (define (hd ol) min )
• (define (tl ol) list sans min )
• (define (order lis) sorted list )

49
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