Encapsulated State

1
Encapsulated State

• Seif Haridi
• Peter Van Roy

2
Encapsulated State
The box O

• The box O can remember information between
  independent invocations, it has a memory
• The basic elements of explicit state
• Index datatypes
• Basic techniques and ideas of using state in
  program design

An Interface that hides the state

• State as a group of memory cells

Group of functions and procedures that
operate on the state
3
Encapsulated State II
The box O

• What is the difference between implicit state and
  explicit state
• What is the difference between state in general
  and encapsulate state
• Component based programming and object-oriented
  programming
• Abstract data types using encapsulated state

An Interface that hides the state

• State as a group of memory cells

Group of functions and procedures that
operate on the state
4
What is state?

• State is a sequence of values in time that
  contains the intermediate results of a desired
  computation
• Declarative programs can also have state
  according to this definition
• Consider the following program

fun Sum Xs A case Xs of XXr then Sum
Xr AX nil then A end end Show
Sum 1 2 3 4 0
5
What is implicit state?

• The two arguments Xs and A
• represent an implicit state
• Xs A
• 1 2 3 4 0
• 2 3 4 1
• 3 4 3
• 4 6
• nil 10

fun Sum Xs A case Xs of XXr then Sum
Xr AX nil then A end end Show
Sum 1 2 3 4 0
6
What is explicit state Example?
An unbound variable
X
C
A cell C is created with initial value 5 X is
bound to C
5
X
C
The cell C, which X is bound to, is assigned
the value 6
6
X
7
What is explicit state Example?
An unbound variable
X

• The cell is a value container with a unique
  identity
• X is really bound to the identity of the cell
• When the cell is assigned, X does not
• change

C
A cell C is created with initialvalue 5 X is
bound to C
5
X
C
The cell C, which X is bound to, is assigned
the value 6
6
X
8
What is explicit state?

• X NewCell I
• Creates a cell with initial value I
• Binds X to the identity of the cell
• Example X NewCell 0
• Assign X J
• Assumes X is bound to a cell C (otherwise
  exception)
• Changes the content of C to become J
• Y Access X
• Assumes X is bound to a cell C (otherwise
  exception)
• Binds Y to the value contained in C

9
Examples

• X NewCell 0
• Assign X 5
• Y X
• Assign Y 10
• Access X 10 returns true
• X Y returns true

0
X
5
X
Y
10
X
Y
10
Examples

• X NewCell 10Y NewCell 10
• X Y returns false
• Because X and Y refer to different cells, with
  different identities
• Access X Access Yreturns true

10
X
10
Y
11
Examples
0
X

• X NewCell 0
• Assign X 5
• Y X
• Assign Y 10
• X 10returns true

5
X
Y
10
X
Y
12
The model extended with cells
Semantic stack (Thread 1)
Semantic stack (Thread n)
.....
w f(x) z person(ay) y ?1 u ?2 x
?1 w ?2 x .... ....
single assignment store
mutable store
13
The stateful model
?s? skip
empty statement ?s1? ?s2?
statement sequence
...
thread ?s1? end thread
creation NewCell ?x? ?c? cell
creation Exchange ?c? ?x? ?y? cell
exchange
Exchange bind ?x? to the old content of ?c? and
set the content of the cell ?c? to ?y?
14
The stateful model
NewCell ?x? ?c? cell creation Exchan
ge ?c? ?x? ?y? cell exchange
Exchange bind ?x? to the old content of ?c? and
set the content of the cell ?c? to ?y?
proc Assign C X Exchange C _ X end fun
Access C X inExchange C X XX end
15
Do we need explicit state?

• Up to now the computation model we introduced in
  the previous lectures did not have any notion of
  explicit state
• And important question is do we need explicit
  state?
• There is a number of reasons for introducing
  state. We discuss them some of them here

16
Programs that changetheir behavior over time

• Declarative program all information is in the
  arguments
• Stateful program new information can be put
  inside a running program

Program
Program
17
Modular programs

• A system (program) is modular if changes
  (updates) in the program are confined to the
  components where the functionality are changed
• Here is an example where introduction of explicit
  state in a well confined way leads to program
  modularity compared to programs that are written
  using only the declarative model (where evey
  component is a function)

18
Encapsulated state I
fun MF fun F ... ?Definition of
F? endfun G ... ?Definition of
G? end in export(fF gG) end M MF

• Assume we have three persons, P, U1, and U2
• P is a programmer who developed a component M
  that provides two functions F and G
• U1 and U2 are system builders that use the
  component M

19
Encapsulated state I

• Assume we have three persons, P, U1, and U2
• P is a programmer who developed a component M
  that provides two functions F and G
• U1 and U2 are system builders that use the
  component M

functor MF export fF gG define fun F ...
?Definition of F? end fun G ...
?Definition of G? end end
20
Encapsulated state II

• User U2 has a demanding application
• He wants to extend the module M to enable him to
  monitor how many times the function F is invoked
  in his application
• He goes to P, and asks him to do so without
  changing the interface to M

fun M fun F ... ?Definition of
F? endfun G ... ?Definition of
G? end in export(fF gG) end
21
Encapsulated state III

• This cannot be done in the declarative model
  because F cannot remember its previous
  invocations
• The only way is to change the interface to F by
  adding two extra arguments FIn and FOut
• fun F ... FIn ?FOut FOut FIn1 ... end
• The rest of the program always remembers the
  previous number of invocations (FIn), and FOut
  returns the new number of invocations
• But this changes the interface!

22
Encapsulated state III
fun MF X NewCell 0 fun F ... Assign
X Access X1 ?Definition of F? endfun G
... ?Definition of G? end fun Count Access
X end in export(fF gG cCount) end M MF

• A cell is created when MF is called
• Due to lexical scoping the cell is only visible
  to the created version of F and Count
• The M.f did not change
• New function M.c is available
• X is hidden only visible inside M (encapsulated
  state)

23
Relationship between the declarative model and
the stateful model

• Declarative programming guarantees by
  construction that each procedure computes a
  function
• This means each component (and subcomponent) is a
  function
• It is possible to use encapsulated state (cells)
  so that a component is declarative from outside,
  and stateful from the inside
• Considered as a black-box the program procedure
  is still a function

24
Programs with accumulators

• local
• fun Sum1 Xs A
• case Xs
• of XXr then Sum1 Xr AX
• nil then A
• end end
• in fun Sum Xs Sum1 Xs 0 end

25
Programs with accumulators
fun Sum Xs fun Sum1 Xs case Xs
of XXr then Assign A XAccess A
Sum1 Xr nil then Access A
end end A NewCell 0 in Sum1 Xs end

• fun Sum Xs
• fun Sum1 Xs A
• case Xs
• of XXr then Sum1 Xr AX
• nil then A
• end end
• in Sum1 Xs 0 end

26
Programs with accumulators
fun Sum Xs fun Sum1 Xs case Xs
of XXr then Assign A XAccess A
Sum1 Xr nil then Access A
end end A NewCell 0 in Sum1 Xs end
fun Sum Xs A NewCell 0 in ForAll Xs
proc X Assign A XAccess A
endAccess A end
27
Programs with accumulators
fun Sum Xs A NewCell 0 in ForAll Xs
proc X Assign A XAccess A
endAccess A end
fun Sum Xs A NewCell 0 in for X in Xs
do Assign A XAccess A endAccess
A end The state is encapsulated inside each
procedure invocation
28
Abstract data types (revisited)

• With encapsulated state, we can complete the
  discussion started in Chapter 4
• For a given functionality, there are many ways to
  package the ADT. We distinguish three axes.
• Open vs. secure ADT is the internal
  representation visible to the program or hidden?
• Declarative vs. stateful ADT does the ADT have
  encapsulated state or not?
• Bundled vs. unbundled ADT is the data kept
  together from the operations or is it separable?
• Let us see what our stack ADT looks like with
  some of these possibilities

29
StackOpen, declarative, and unbundled

• Here is the basic stack, as we saw it
  beforefun NewStack nil endfun Push S E
  ES endfun Pop S E case S of XS1 then EX S1
  end endfun IsEmpty S Snil end
• This is completely unprotected. Where is it
  useful? Primarily, in small programs in which
  expressiveness is more important than security.

30
StackSecure, declarative, and unbundled

• We can make the declarative stack secure by using
  a wrapperlocal Wrap Unwrapin NewWrapper
  Wrap Unwrap fun NewStack Wrap nil end fun
  Push S E Wrap EUnwrap S end fun Pop S E
  case Unwrap S of XS1 then EX Wrap S1 end
  end fun IsEmpty S Unwrap S nil endend
• Where is this useful? In large programs where we
  want to protect the implementation of a
  declarative component.

31
StackSecure, stateful, and bundled

• This is the simplest way to make a secure
  stateful stackproc NewStack Push Pop
  IsEmpty CNewCell nilin proc Push X
  Assign C XAccess C end fun Pop case
  Access C of XS then Assign C S X end
  end fun IsEmpty C Access C nil endend
• Compare the declarative with the stateful
  versions the declarative version needs two
  arguments per operation, the stateful version
  uses higher-order programming (instantiation)
• With some syntactic support, this gives
  object-oriented programming

32
StackSecure, stateful, and unbundled

• Let us combine the wrapper with statelocal Wrap
  Unwrapin NewWrapper Wrap Unwrap fun
  NewStack Wrap NewCell nil end proc Push W
  X CUnwrap W in Assign C XAccess C
  end fun Pop W CUnwrap W in case Access
  C of XS then Assign C S X end end fun
  IsEmpty S Access Unwrap Wnil end end
• This version is stateful but lets us store the
  stack separate from the operations. The same
  operations work on all stacks.

33
Four ways to package a stack

• Open, declarative, and unbundled the usual
  declarative style, e.g., in Prolog and Scheme
• Secure, declarative, and unbundled use wrappers
  to make the declarative style secure
• Secure, stateful, and bundled the usual
  object-oriented style, e.g., in Smalltalk and
  Java
• Secure, stateful, and unbundled an interesting
  variation on the usual object-oriented style
• Other possibilities there are four more
  possibilities! Try to write all of them.

34
Indexed Collections

• Indexed collections groups a set of (partial)
  values
• The individual elements are accessible through an
  index
• The declarative model provides
• tuples, e.g. date(17 december 2001)
• records, e.g. date(day17 monthdecemeber
  year2001)
• We can now add state to the fields
• arrays
• dictionaries

35
Arrays

• An array is a mapping from integers to (partial)
  values
• The domain is a set of consecutive integers, with
  a lower bound and an upper bound
• The range can be mutated (change)
• A good approximation is to thing of arrays as a
  tuple of cells

36
Operations on arrays

• A Array.new LB UB ?Value
• Creates an array A with lower bound LB and upper
  bound UB
• All elements are initialized to Value
• There are other operations
• To access and update the elements of the array
• Get the lower and upper bounds
• Convert an array to tuple and vice versa
• Check its type

37
Example 1
fun MakeArray L H F A Array.new L H
unit in for I in L..H do A.I F I
end A end

• A MakeArray L H F
• Creates an array A where for each index I is
  mapped to F I

38
Array2Record

• R Array2Record L A
• Define a function that takes a label L and an
  array A, it returns a record R whose label is L
  and whose features are from the lower bound of A
  to the upper bound of A
• We need to know how to make a record
• R Record.make L Fs
• creates a record R with label L and a list of
  features (selector names), returns a record with
  distict fresh variables as values
• L Array.low A and H Array.high A
• Return lower bound and higher bound of array A

39
Array2Record

• fun Array2Record LA A
• L Array.low A
• H Array.high A
• R Record.make LA From L H
• in
• for I in L..H do
• R.I A.I
• end
• R
• end

40
Tuple to Array

• fun Tuple2Array T
• H Width T
• in
• MakeArray
• 1 H
• fun I T.I end
• end

41
Dictionaries (Hash tables)

• A dictionary is a mapping from simple values or
  literals (integers, atoms, amd names) to
  (partial) values
• Both the domain and the range can be mutated
  (changed)
• The pair consisting of the literal and the value
  is called an item
• Items can be added, changed and removed in
  amortized constant time
• That is to say n operations takes on average O(n)

42
Operations on dictionaries

• D Dictionary.new
• Creates an empty dictionary
• There are other operations
• To access and update (and add) the elements of a
  dictionary using the . and notations
• Remove an item, test the memership of a key
• Convert a dictionary to a record and vice versa
• Check its type

43
Indexed Collections
stateless collection
Tuple
Add state
Add atoms as indices
stateful collection
Array
Record
Add atoms as indices
Add state
Dictionary
44
Other collections
stateless collection
lists
potentially infinite lists
ports
streams
stateful collection
generalizes streams to stateful mailboxes
stacks
queues
stateless
45
Encapsulated stateful abstract datatypes ADT

• These are stateful entities that can be access
  only by the external interface
• The implementation is not visible outside
• The are two method to build stateful abstract
  data types
• The functor based approach (record interface)
• The procedure dispatch approach

46
The functor-based approach

• fun NewCounter I
• S Record.toDictionary state(vI)
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• in o(incInc decDec getGet putPut
  showDisplay)
• end

47
The functor-based approach

• fun NewCounter I
• S Record.toDictionary state(vI)
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• in o(incInc decDec getGet putPut
  showDisplay)
• end

The state is collected in dictionary S The state
is completely encapsulated i.e. not visible out
side
48
The functor-based approach

• fun NewCounter I
• S Record.toDictionary state(vI)
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• in o(incInc decDec getGet putPut
  showDisplay)
• end

The interface is created for each instance
Counter
49
The functor-based approach

• fun NewCounter I
• S Record.toDictionary state(vI)
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• in o(incInc decDec getGet putPut
  showDisplay)
• end

function that access the state by lexical scope
50
Call pattern

• declare C1 C2
• C1 NewCounter 0
• C2 NewCounter 100
• C1.inc
• C1.show
• C2.dec
• C2.show

51
Defined as a functor

• functor Counter
• export incInc decDec getGet putPut
  showDisplay initInit
• define
• S
• proc Init init(I) S Record.toDictionary
  state(vI) end
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• end

52
Functors

• Functors have been used as a specification of
  modules
• Also functors have been used as a specification
  of abstract datatypes
• How to create a stateful entity from a functor?

53
Explicit creation of objects from functors

• Given a variable F that is bound to a functor
• O Module.apply Fcreates stateful ADT
  object O that is an instance of F
• Given the functor F is stored on a file f.ozf
• O Module.link f.ozfcreates stateful
  ADT object O that is an instance of F

54
Defined as a functor

• functor Counter
• export incInc decDec getGet putPut
  showDisplay initInit
• define
• S
• proc Init init(I) S Record.toDictionary
  state(vI) end
• proc Inc S.v S.v 1 end
• proc Dec S.v S.v 1 end
• fun Get S.v end
• proc Put I S.v I end
• proc Display Show S.v end
• end

55
Pattern of use

• fun New Functor Init
• M Module.apply Functor
• M.init Init
• M
• end
• declare C1 C2
• C1 New Counter init(0)
• C1.inc C1.show
• C2.inc C2.show

56
Examplememoization

• Stateful programming can be used to speed up
  declarative (functional) components by
  remembering previous results
• Consider the pascal triangle
• One way to make it faster between separate
  invocations is to remember previously computed
  rows
• Here follow our principle and change only the
  internals of a component

57
Functions over lists
1

• Compute the function Pascal N
• Takes an integer N, and returns the Nth row of a
  Pascal triangle as a list
• For row 1, the result is 1
• For row N, shift to left row N-1 and shift to the
  right row N-1
• Align and add the shifted rows element-wise to
  get row N

1
1
1
2
1
(0)
1
3
3
1
(0)
1
4
6
4
1
0 1 3 3 1 1 3 3 1 0
Shift right
Shift left
58
Faster Pascal
fun FastPascal N if N1 then 1 else
local L in LFastPascal N-1
AddList ShiftLeft L ShiftRight L end
end end

• Introduce a local variable L
• Compute FastPascal N-1 only once
• Try with 30 rows.
• FastPascal is called N times, each time a list on
  the average of size N/2 is processed
• The time complexity is proportional to N2
  (polynomial)
• Low order polynomial programs are practical.

59
Memoizing FastPascal

• FastPascal N New Version
• Make a store S available to FastPascal
• Let K be the number of the rows stored in S (i.e.
  max row is the Kth row)
• if N is less or equal K retrieve the Nth row from
  S
• Otherwise, compute the rows numbered K1 to N,
  and store them in S
• Return the Nth row from S
• Viewed from outside (as a black box), this
  version behaves like the earlier one but faster

declare S Module.apply StoreFun S.put 2
1 1 Browse Get S 2 Browse Size
S (see the program)
60
The store functor

• functor
• export putPut getGet sizeSize
• define
• S NewDictionary
• C NewCell 0
• proc Put K X
• if Not Dictionary.member S K then
• Assign C Access C1
• end
• S.K X
• end
• fun Get K S.K end
• fun Size Access C end
• end

61
The Pascal functor

• functor PascalFun
• import S at 'Store.ozf System
• export
• pascalFastPascal
• define
• fun FastPascal N ?Definition of Pascal? end
• ?Definition of help procedures for Pascal?
• S.put 1 1
• end

62
Memo pascal

• fun FastPascal N
• MaxRow in
• MaxRow S.size
• if N lt MaxRow then
• S.get N
• else L in
• ?Compute the next N-MaxRow rows stating from
  row the value of MaxRow, call this list of
  rows L?
• PutList S MaxRow1 L
• S.get N
• end
• end

63
Memo pascal

• fun FastPascal N
• MaxRow in
• MaxRow S.size
• if N lt MaxRow then
• S.get N
• else L in
• L PascalListNext N-MaxRow S.get
  MaxRow
• PutList S MaxRow1 L
• S.get N
• end
• end

64
The procedure dispatch approach

• Another method to realize stateful ADT is the
  procedure dispatch approach
• The instance of the ADT is a one argument
  procedure
• The procedure receives messages (when called)
• and dispatches to the right function according to
  the label of the message
• State is encapsulated
• The interface is defined as messages (implemented
  as records)

65
The procedure-based approach

• fun NewCounter I
• S Record.toDictionary state(vI)
• proc Inc inc S.v S.v 1 end
• proc Dec dec S.v S.v 1 end
• procGet get(I) I S.v end
• proc Put put(I) S.v I end
• proc Display show Show S.v end
• D o(incInc decDec getGet putPut
  showDisplay)
• in proc M D.Label M M end
• end

66
Call pattern

• declare C1 C2
• C1 NewCounter 0
• C2 NewCounter 100
• C1 put(10) C1 inc
• declare X C1 get(X)
• C1 show
• C2 dec
• C2 show

67
Declarative vs. Stateful

• We are going to study two different
  implementations of an algorithm, one using
  stateful data type representation and the other
  uses stateless representation
• The stateful representation will lead to a
  stateful (imperative) algorithm
• The stateless representation will lead to a
  declarative (functional) algorithm
• We start from the abstract description of the
  algorithm
• Which approach is better? We will see!

68
Transitive closure

• A directed graph consists of a set of vertices
  (nodes) V and a set of edges (represented as set
  of pairs of vertices) E
• (vi,vj) ? E iff there is an edge from vi to vj

2
3
1
1,2,3,4,5,6 (1,2), (2,3), (3,4), (4,5),
(5,6),(6,2) (1,2)
The vertices
The edges
4
6
5
69
Transitive closure

• Calculate a new graph TG, from the original graph
  G such that TG is the transitive closure of G
• That is to say there is an edge between a pair of
  nodes (i,j) in TG iff there is a path from i to j
  in the graph G

70
Transitive closure
The set of immediate predecessors on node I,
Pred(I) The set of immediate successors on node
I, Suc(I)
2
3
Pred(2) 1 6 5 Suc(2) 3
1
4
6
5
71
The algorithm works by transforming the graph
incrementally
72
The algorithm works by transforming the graph
incrementally
2
2
3
3
1
1
4
4
6
6
5
5
73
The abstract algorithm

• For each node x in the graph G
• For each node y in Pred(x)
• For each node z in Suc(x) add the edge (y,z) to G

74
The representation

• The representation determines very much the model
  of implementation
• List (tree) based representation is suitable for
  a declarative formulation
• Array (dictionary) based representation is
  suitable for a stateful formulation

75
Representation

• The adjacency list representation
• The graph is a list of elements of the form INs
• I is the node identifier, Ns is the list of
  successor nodes
• The matrix representation
• The graph is a two dimensional array GM where
  GM.I.J is true iff there is an edge from node I
  to node J

76
Transitive closure

• The matrix representation
• M is the matrix

M.I.K true
M.K.J true M.L.K false
I
J
K
L
77
From abstract to concreteMatrix representation

• For each node K in the graph G
• For each node I in Pred(K)
• For each node J in Suc(K) add the edge (I,J) to G

proc StateTrans GM LArray.low GM
HArray.high GM in for K in L..H do ?For
each in I in Pred(K) For each J in Suc(K)
add GM.I.J true ? end end
78
From abstract to concreteMatrix representation

• For each node K in the graph G
• For each node I in Pred(K)
• For each node J in Suc(K) add the edge (I,J) to G

proc StateTrans GM LArray.low GM
HArray.high GM in for K in L..H do for
I in L..H do if GM.I.K then For
each J in Suc(K) add
GM.I.J true ? end end end
79
From abstract to concreteMatrix representation
proc StateTrans GM L H ... in for K
in L..H do for I in L..H do if GM.I.K
then for J in L..H do if
GM.K.J then GM.I.J true
end end end if end for
end for end
proc StateTrans GM LArray.low GM
HArray.high GM in for K in L..H do for
I in L..H do if GM.I.K then For
each J in Suc(K) add
GM.I.J true ? end end end
80
From abstract to concreteMatrix representation
proc StateTrans GM L H ... in for K
in L..H do for I in L..H do if GM.I.K
then for J in L..H do if
GM.K.J then GM.I.J true
end end end if end for
end for end
proc StateTrans GM LArray.low GM
HArray.high GM in for K in L..H do for
I in L..H do if GM.I.K then For
each J in Suc(K) add
GM.I.J true ? end end end
81
From abstract to concreteMatrix representation
proc StateTrans GM L H ... in for K
in L..H do for I in L..H do if GM.I.K
then for J in L..H do if
GM.K.J then GM.I.J true
end end end if end for
end for end
proc StateTrans GM L H ... in for K
in L..H do for I in L..H do if GM.I.K
then for J in L..H do
GM.I.J GM.I.J orelse GM.K.J end end
if end for end for end
82
Transitive closureadjacency lists
1 2 2 1 3 3 4 4 5 5
2 6 2
The immediate successor list is sorted, e.g. 2
1 3
2
3
1
4
6
5
83
From abstract to concreteAdjacency list
representation

• For each node X in the graph G
• For each node Y in Pred(X)
• For each node Z in Suc(X) add the edge (Y,Z) to
  G

fun DeclTrans G Xs Nodes G in FoldL Xs
fun InG X SX Suc X ?For
each node Y in Pred(X) For each Z in SX add
edge (Y,Z) ? end G end
G0, F G0 X0 , F F G0 X0 X1, ...
This is FoldL Xs F G0
84
From abstract to concreteAdjacency list
representation
fun IncPath X SX InG Map InG fun
YSY YIf ?Y in Pred(X) ? then Union SY
SX else SY end end end
fun DeclTrans G Xs Nodes G in FoldL Xs
fun InG X SX Suc X ?For
each node Y in Pred(X) For each Z in SX add
edge (Y,Z) in GC ? end
G end
?For each node Y in PX For each Z in SX add
edge (Y,Z) in GC ?
85
From abstract to concreteAdjacency list
representation
fun IncPath X SX InG Map InG fun
YSY YIf Member X SY then Union SY
SX else SY end end end
fun DeclTrans G Xs Nodes G in FoldL Xs
fun InG X SX Suc X ?For
each node Y in Pred(X) For each Z in SX add
edge (Y,Z) in GC ? end
G end
Y in Pred(X) if and only if X in Pred(Y)
86
Conclusion

• The stateful algorithm was straight forward in
  this case
• The declarative algorithm was a bit harder
• Both algorithms are of O(n3)
• In the declarative algorithm we assume Successor
  list is sorted
• Union is just implemented by mergeing sorted
  lists O(n)
• We exploited the fact that Y in Pred(X) if and
  only if X in Pred(Y)
• The declarative one is better if the graph is
  sparse (many elements in the martix are false)

87
System building

• Abstraction is the best tool to build complex
  system
• Complex systems are built by layers of
  abstractions
• Each layer have to parts
• Specification, and
• Implementation
• Any layer uses the specification of the lower
  layer to implement its functionality

88
Properties needed to support the principle of
abstraction

• Encapsulation
• Hide internals from the interface
• Compositionality
• Combine parts to make new parts
• Instantiation/invocation
• Create new instances of parts

89
Component base programming

• Supports
• Encapsulation
• Compositionality
• Instantiation

90
Object-oriented programming

• Supports
• Encapsulation
• Compositionality
• Instantiation
• Plus
• Inheritance

91
Component-based programming

• Good software is good in the large and in the
  small, in its high level architecture and in its
  low-level details. In Object-oriented software
  construction by Bernard Meyer
• What is the best way to build big applications?
• A large application is (almost) always built by a
  team
• How should the team members communicate?
• This depends on the applications structure
  (architecture)
• One way is to structure the application as a
  hierarchical graph

92
Component-based programming
Interface
External world
Component instance
93
Component based design

• Team members are assigned individual components
• Team members communicate at the interface
• A component, can be implemented as a record that
  has a name, and a list of other component
  instances it needs, and a higher-order procedure
  that returns a component instance with the
  component instances it needs
• A component instance has an interface and an
  internal entities that serves the interface

94
Model independence priciple

• As the system evolves, a component implementation
  might change or even the model changes
• declarative (functional)
• stateful sequential
• concurrent, or
• relational
• The interface of a component should be
  independent of the computation model used to
  implement the component
• The interface should depend only on the
  externally visible functionality of the component

95
Examplememoization

• Consider the pascal triangle
• One way to make it faster between separate
  invocations is to remember previously computed
  rows
• Here follow our principle an change only the
  interna of a component

96
What happens at the interface?

• The power of the component based infrastructure
  depends on large extent on the expressiveness of
  the interface
• How does components communicate with each others?
• We have three possible case
• The components are written in the same language
• The components are written in different languages
• The components are written in different
  computation model

97
Components in the same language

• This is easy
• In Mozart/Oz component instances are modules
  (records whose fields contain the various
  services provided by the component-instance part
• In Java, interfaces are provided by objects
  (method invocations of objects)
• In Erlang component instances are mainly
  concurrent processes (threads), communication is
  provided by sending asynchronous messages

98
Components in different languages

• An intermediate common language is defined to
  allow components to communicate given that the
  language provide the same computation model
• A common example is CORBA IDL (Interface
  Definition Language) which maps a language entity
  to a common format at the client component, and
  does the inverse mapping at the service-provider
  component
• The components are normally reside on different
  operating system processes (or even on different
  machines)
• This approach works if the components are
  relatively large and the interaction is
  relatively infrequent

99
Illustration (one way)
A component C1 calling the function (method)
f(x) in the Component C2
Translate f(x) from language L1 (structured
data) to IDL (sequence of bytes)
Translate f(x) from language IDL (sequence of
bytes) to language L2 (structured data)
A component C2 invoking the function (method)
f(x)