A Protocol for Distributed Cooperative Work - Semantic Scholar

FCT'99

Final Version

A Protocol for Distributed Cooperative Work Joseph Goguen

Department of Computer Science & Engineering University of California at San Diego Grigore Rosu 1

Department of Computer Science & Engineering University of California at San Diego

Abstract

After a brief review of hidden algebra, we give behavioral speci cations for set theory and closure operators, and then use these to give a behavioral speci cation of an abstract protocol to support distributed cooperative work structured by dependencies in such a way as to form what we call a weak closure operator. We give some correctness proofs for this protocol, and then describe a concrete instance of it, called the tatami protocol, that supports distributed cooperative proving. Finally, we draw some methodological conclusions.

1 Introduction The internet and the world wide web have profoundly altered many aspects of our information behavior. For example, many people now prefer email over physical mail or telephone, and would rather re up a search engine than go to the library, even their own private library. Distributed cooperative work over the internet seems to be a long term trend, one early indication of which is the popularity of web-based bookstores. But many informational activities have changed very little; for example, most mathematical proofs are still done on paper by individuals. To be sure, whiteboards are replacing blackboards, computers are often used for tedious calculations, research papers are often fetched over the web, and there are numerous specialized mathematical email discussion groups; but most proofs are still done by hand, and nearly always by individuals. On leave from Fundamentals of Computing, Faculty of Mathematics, University of Bucharest, Romania. To be published in Electronic Notes in Theoretical Computer Science URL: www.elsevier.nl/locate/entcs

1

Goguen and Rosu

The contrast between mathematics and software engineering is striking. Today the internet and web typically play a large role in software engineering, especially for larger rms. Although organized small groups of mathematicians working on a single problem are not uncommon, tightly organized large groups are unknown, to say nothing of separate subgroups devoted to requirements, speci cation, testing, documentation, maintenance, and marketing. However, the increasing interest in formal methods is forcing consideration of how mathematical activities, especially formal proving, might be integrated into software development processes, and in particular, how such activities might be supported over the internet. This paper presents a novel internet protocol that was developed as part of a larger project to make formal methods more available for software engineering [10,6]. The protocol supports asynchronous distributed cooperative work, and in particular mathematical proving, in an open environment where packets can be lost, corrupted, or received out of order. Much of the paper is devoted to specifying and proving properties of this protocol, using methods and tools related to the larger project, particularly hidden algebra and the CafeOBJ language and system [6]. Actually, we rst specify an abstract protocol to support distributed cooperative work on any data structure involving dependencies that de ne a (weak form of) closure operator; no form of centralization of data or control is assumed. This protocol is general enough to include many instantiations other than theorem proving. For example, consider an architectural rm with workers at multiple locations for the same job, such a central oce, a branch oce, and a construction site; most jobs will involve multiple kinds of documents, such as blueprints, site drawings, lists of abbreviations, etc., and there will be multiple revisions and versions for each kind of document, as well as complex dependencies among documents. This is just one of many examples where a protocol for distributed cooperative work that can take account of complex dependencies would be useful. Section 2 reviews hidden algebra, which is the basis for our speci cations and proofs, and Section 2.3 discusses rsome elated work in that area. After that, Section 3 gives behavioral speci cations for set theory and closure operators, and Section 4 gives the abstract protocol speci cation; in each case, some behavioral properties are proved. Section 5 describes the tatami protocol, an instantiation of the abstract protocol to support proving, and Section 6 draws some overall methodological conclusions. From an application point of view, the most novel aspect of this paper is the very general way that the abstract protocol is parameterized by dependencies among messages, including even non-monotonic dependencies; for the concrete tatami protocol, the use of fuzzy truth values for boolean formulae is interesting, in addition to the way that it handles dependencies.

2

Goguen and Rosu

2 Hidden Algebra Hidden algebra [8,9] gives a general semantics for distributed concurrent systems; see [13] for a recent survey of the case where all operations are behavioral and have at most one argument hidden. The goal of hidden algebra is to significantly decrease the diculty of proving properties of distributed concurrent systems. We now brie y review the basic de nitions and results in the slightly extended form developed in [24,14,5], assuming familiarity with the basics of algebraic speci cation (for which see e.g. [12,15]). De nition 2.1 A hidden signature is a triple ( ; D; ), often denoted just , where  is a V -sorted signature and D is a -algebra, called the data algebra,   is a (V [ H )-sorted signature extending and such that each operation in  with both its arguments and its result visible lies in , and  V and H are disjoint sets, called visible sorts and hidden sorts, respectively. A hidden subsignature of  is a hidden signature ( ; D; ?) with ?  . A behavioral (or hidden) -speci cation or theory is a triple (; ?; E ), where  is a hidden signature, ? is a hidden subsignature of , and E is a set of -equations. The operations in ? ? are called behavioral. A hidden -algebra is a many sorted -algebra A such that Aj = D. This drops the restriction of [8,13] to operations with at most one hidden argument. Operations in  with one hidden argument and visible result may be called attributes, those with one hidden argument and hidden result methods, and those with visible arguments and hidden result (generalized) hidden constants. The data algebra should include any xed data representations that are to be shared among various methods and processes, at potentially dierent locations. These might include, e.g., the real numbers (which cannot be speci ed in any rst order logic), for example, to handle statistical calculations, or real time processes. However, we wish to note that none of the results used in this paper require the assumption of a xed data algebra D, so that it could be loosely speci ed, instead of being xed in advance. De nition 2.2 Given a hidden -algebra A and an equivalence  on A, an operation  in s1 :::sn;s is congruent 2 for  i A (a1 ; :::; an)  A (a01 ; :::; a0n) whenever ai  a0i for i = 1; :::; n. A hidden ?-congruence on A is an equivalence on A which is the identity on visible sorts and such that each operation in ? is congruent for it. Theorem 2.3 Given a hidden subsignature ? of  and a hidden -algebra A, there exists a largest hidden ?-congruence on A, called ?-behavioral equivalence and denoted ?. 2

This notion was rst introduced by Padawitz [20] under the name \compatible."

3

Goguen and Rosu

The above result (from [24]) generalizes [13] to behavioral operations that may have more than one hidden argument. The relation ? may be de ned as follows [24]: Given a hidden signature ?, an (appropriate) ?-context 3 of sort s is a visible term in T?(fzg [ Z ) with exactly one occurrence of a special variable (\special" means it is dierent from any other variable in this situation) z of sort s, where Z is an in nite set of special variables. Let C?[z : s] denote the set of all ?-contexts of sort s, and var(c) the nite set of variables in c, excluding z. Given a hidden signature , a hidden subsignature ? of , and a -algebra A, a ?-context c determines a map Ac : As  Avar(c) ! D by Ac(a; ) = a (c), where a is the unique extension of the map (denoted a ) that takes z to a and each z0 2 var(c) to (z0 ). Then ? is given by a ? a0 i Ac(a; ) = Ac(a0; ) for all ?-contexts c and all  : var(c) ! A. De nition 2.4 An operation  is ?-behaviorally congruent for A i  is congruent for ? ; we will often say just \congruent" instead of \behaviorally congruent". A hidden -algebra A ?-behaviorally satis es a -equation e = ?(8X ) t = t0 i for each  : X ! A, (t) ? (t0?); in this case we write A j e. If E is a set of -equations, we write A j E if A ?-behaviorally satis es each equation in E . When  and ? are clear from context, we may write  and j instead of ? and j? respectively. We say that A behaviorally?satis es (or is a model of) a behavioral speci cation B = (; ?; E ) i A j E , and in this case we write A j B; also B j e means A j B implies A j? e. We now introduce some conventions to simplify notation: Given an operation  2 s1:::sn;s and a set W = fw1 : s1 ; :::; wn : sng of variables, we may write (W ) instead of (w1; :::; wn); when we are only interested in one argument of , say the j th, we may write it as the last argument; moreover, if W = fw1 : s1; :::; wj?1 : sj?1; wj+1 : sj+1; :::; wn : sng and if x : sj then (W; x) denotes the term (w1; :::; wj?1; x; wj+1; :::; wn). Given a hidden sort h (or a term t of sort h), an operation  2  is appropriate for h (or t) i  has at least one argument of sort h. When we say that a property holds for all appropriate , we mean for all appropriate arguments of . For example, given two hidden sorted terms t; t0 2 T;h(X ), the assertion \((W; t); (W; t0)) 2 G for all appropriate  2 " means that ((w1; :::; wj?1; t; wj+1; :::; wn); (w1; :::; wj?1; t0; wj+1; :::; wn)) 2 G for all  2 s1 :::sn;s and all j 2 1; :::; n such that sj = h. 2.1 Hidden Algebra and Equational Deduction Ordinary equational deduction is not sound for behavioral satisfaction. This is because the congruence rule of deduction is not sound for operations that Contexts can be thought of as \experiments" on a system, consisting of a number of methods followed by the \measurement" of an attribute.

3

4

Goguen and Rosu

are not behaviorally congruent. Since behavioral equivalence is the identity on visible sorts, we modify the congruence rule to obtain the following: (1) Re exivity: (8X ) t = t ) t = t0 (2) Symmetry: ((88X X ) t0 = t 0 0 00 (3) Transitivity: (8X ) t(=8Xt ); t(8=Xt)00 t = t

(4) Substitution: (8Y ) l = r 2 E;  : Y ! T (X ) (8X ) (l) = (r)

(5) Congruence:

8 (8X ) t = t0; sort(t; t0) 2 V > a ) > > < (8X; W ) (W; t) = (W; t0); for each  2  > > (8X ) t = t0 ; sort(t; t0) 2 H > b ) :

(8X; W ) (W; t) = (W; t0 ); for all congruent  2 

9 > > > = > > > ;

Because of (5b), the more congruent operations there are, the more behavioral equalities can be proved. Since all behavioral operations and all hidden constants are behaviorally congruent, there always are many cases where (5b) can be applied. All the above rules are sound for behavioral satisfaction [24]: Proposition 2.5 B  (8X ) t = t0 implies B j (8X ) t = t0. Moreover, if all operations are congruent, then ordinary equational deduction is sound for behavioral satisfaction. 2.2 Cobases and Coinduction Induction is used to prove ordinary equations in the framework of abstract data types. The notion of basis, as a set of operations that generates all terms, plays an important role in induction, and a good choice of basis can often greatly simplify a proof. Dually, coinduction is used to prove behavioral sentences over behavioral theories, and a cobasis is a set of operations (or derived operations, or even more generally, operations in a conservative extension) that cogenerates the behavioral equivalence of terms: De nition 2.6 If B0 = (0 ; ?0; E 0) is a conservative extension of B = (; ?; E ) and if
 0 , then
is a cobasis for B i for all hidden sorted terms t; t0 2 T;h(X ), if B0 j (8W; X ) (W; t) = (W; t0) for all appropriate  2
then B j (8X ) t = t0 . 5

Goguen and Rosu

This notion of cobasis is a weaker version of the more observation oriented one in [24]. There are methods for obtaining cobases for B automatically when B0 = (Der(); ?; E ), where Der() is the derived signature of  (for example, see [19]), and it is not hard to see that B0 = (Der(); ?; E ) is a conservative extension of B. The following reformulates a result from [24]: Proposition 2.7 Given a behavioral speci cation B = (; ?; E ) , then
= ? is a cobasis for B, when B0 is either B or (Der(); ?; E ). De nition 2.8 Speci cations B1 = (; ?1 ; E1) and B2 = (; ?2 ; E2) are equivalent i they have the same models (hidden algebras) with the same behavioral equivalence on them; in this case, we write B1  B2 . Notice that  is an equivalence relation on behavioral speci cations, that B0 is a conservative extension of B whenever B  B0 , and that B00 is a conservative extension of B whenever B0 is a conservative extension of B and B0  B00 . The next two results are useful for checking cobases, which with coinduction gives a powerful inference technique for proving behavioral satisfaction. Theorem 2.9 If B1 = (; ?1; E ) and B2 = (; ?2; E ) are behavioral speci cations such that ?1  ?2 and E contains no equation with hidden sorted conditions, then B1  B2 i all operations in ?2 ??1 are behaviorally congruent for B2 ; and in this case, ?1 is a cobasis for B2 . Proof. The equivalence is proved in [24] (Theorem 20). By Proposition 2.7, ?1 is a cobasis for B1 . If B1  B2 then B1 j (8X ) t = t0 i B2 j (8X ) t = t0 for any -equation (8X ) t = t0 , so ?1 is also a cobasis for B2 . 2 The restriction to equations with visible conditions seems not to be an inconvenience for practical examples. Proving behavioral congruence of operations may not be easy, and can require coinduction [24]. However, we have developed a syntactic criterion that is adequate for many situations, including all those in this paper [24]: Proposition 2.10 Congruence Criterion: Let B = (; ?; E ) be a hidden speci cation and  an operation in . If for each appropriate  in ? there is some in T? (Z [ W ) such that the -equation (8Z; W ) (Z; (W )) = is in E (modulo renaming of variables), then  is behaviorally congruent for B. The above is a special case of Theorem 16 of [24]. A more general and more complex criterion appears in [3], though it too follows from Theorem 16 of [24]. Given a cobasis
of B, the following rule called
-coinduction is sound for behavioral satisfaction:

t0 ) for all appropriate  2
(6)
-Coinduction: (8W; X ) (W; t) = ((W; 8X ) t = t0 We call this
-coinduction because ordinary coinduction is the special case where B0 = B and
= ?. More precisely, given a hidden -algebra A, consider 6

Goguen and Rosu

a relation R on A having the property a R a0 i (a1 ; :::; an; a) R (a1; :::; an; a0) for all appropriate  2
(= ?) and a1; :::; an 2 A. Then all operations in
are congruent for any such relation; therefore any such relation is a hidden ?-congruence and by Theorem 2.3, R  ?. Note also that ? is such a relation. Now from [24] we have: Proposition 2.11 De ne 
by B 
(8X ) t = t0 i (8X ) t = t0 is derivable from B under rules (1){(6). Then 
is sound for behavioral satisfaction whenever
is a cobasis for B. Notice that 
is not necessarily sound with respect to ordinary equational satisfaction. The special case of
-coinduction where
consists of all the attributes is called attribute coinduction. Both the Kumo system [11,10] and CafeOBJ [6] implement this special case, and Kumo will soon also implement the more general coinduction rule (6). We have found that proofs using hidden coinduction can be considerably simpler than proofs using more traditional techniques. 2.3 Related Work An adequate discussion of the complex historical and technical relations among the many approaches to behavioral speci cation is not possible in any short space, but we will do our best to be sound, if not complete. Behavioral satisfaction was introduced in 1981 by Reichel [22], hidden algebra in 1989 by Goguen [8], multiple hidden arguments and congruent and behavioral operations in 1992 by Bernot, Bidoit and Knapik [1], and non-congruent operations in 1998 by Diaconescu [5]. De ning operations congruent over behavioral equivalence by a subset of operations seems to have rst occurred in [1]. Similar ideas appear in [20,21,24], as well as [6,5,17], which use the term behavioral coherence, but we prefer the term \congruent" because the congruence rule of equational deduction is sound in behavioral logic for an operation i that operation is behaviorally congruent. All these ideas were previously integrated in [24], while [14] gives some new examples, institutions, and results relating hidden algebra to information hiding. Hidden algebra models have a xed subalgebra of data values, as distinct from the observational logic of Bidoit and Hennicker ([1,2,17], etc.) and the semantics of CafeOBJ [6]. This seems desirable because real applications use standard booleans and integers rather than arbitrary models of some theory; nevertheless, all results of this paper hold for the fully loose semantics, and there are applications where this is useful, although perhaps these would be better handled by parameterization. Also, our models do not require that all operations are congruent as in [17,20]; non-congruent operations seem necessary for applications like length for lists implemented as sets. Our approach also avoids the in nitary logic used in observational logic. Coalgebra is an elegant related approach (e.g., [18]), which however lacks nondeterminism, multiple hidden arguments, and other features that seem 7

Goguen and Rosu

important for applications; one symptom of the dierence is that nal algebras no longer exist for the version of hidden algebra used in this paper. The latest information on hidden algebra, including our most recent papers, links to related work by other researchers, and links to online tutorial material, can be found at www.cs.ucsd.edu/users/goguen/projs/halg.html, the hidden algebra homepage.

3 Behavioral Speci cations of Sets and Closures This section gives some speci cations that are needed later, beginning with a behavioral speci cation for a fragment of set theory. The usual de nition of set equality is in fact behavioral: two sets are equal i they have the same elements, where membership is a boolean valued attribute. However, the usual representation for sets, as lists within curly brackets, does not directly re ect this equality, so that equations like f1; 2g = f2; 2; 1g have confused generations of school children. Similarly, the usual de nitions of operations like union and intersection in terms of membership are also behavioral. To achieve exibility, we parameterize sets by elements with equality, assuming only re exivity and commutativity of equality, but not transitivity. Although the CafeOBJ parser does not accept the code below because CafeOBJ does not support behavioral operations with multiple hidden arguments [6], we nevertheless use its syntax. Here \mod*" indicates loose semantics, \[ Elt ]" indicates an ordinary sort, \*[ Set ]*" indicates a hidden sort, \op" indicates an operation declaration, with underbars as placeholders for arguments of the sorts that come between \:" and \->", with the value sort coming after the \->", and with \{com}" declaring the commutative axiom; behavioral operations have a similar syntax, with keyword \bop." Behavioral equations (i.e., equations that need only be satis ed behaviorally) are indicated with the keyword \beq" and ordinary equations with \eq". The parameterization of SET-BASIC by TRIV-EQ is indicated by \(X :: TRIV-EQ)", meaning that once we instantiate SET-BASIC with some set with equality, we get a speci cation for subsets of that set 4 . mod* TRIV-EQ f [ Elt ] op _eq_ : Elt Elt -> Bool fcommg vars E : Elt eq E eq E = true . g mod* SET-BASIC(X :: TRIV-EQ) f *[ Set ]* bop _in_ : Elt Set -> Bool bop f_g : Elt -> Set bop _U_ : Set Set -> Set bop _-_ : Set Set -> Set vars S S' : Set vars E E' : Elt

If desired, Elt could have been declared as a hidden sort; however, our applications use only the visible case.

4

8

Goguen and Rosu beq E in fE'g = E eq E' . beq E in S U S' = E in S or E in S' . beq E in S - S' = E in S and not E in S' . g

All the set operations here are behavioral, i.e., they preserve set equality. For the set speci cation with only in declared behavioral, the singleton operation is a generalized constant and therefore congruent, and the congruence criterion gives us that union and dierence are also congruent. Therefore Theorem 2.9 implies that
= fing is a cobasis for SET-BASIC, so that the above speci cation is equivalent to the speci cation with in as the only behavioral operation. Thus we can use
-coinduction to prove behavioral equations such as the commutativity, associativity, and idempotence of union, and the two equations below, for all sets S, S', S'': beq (S - S') - S'' = S - (S' U S'') . bceq (S U S') - fEg = S U (S' - fEg) if not E in S .

In the following proof score for the above equations, \red" indicates reduction (i.e., rewriting, in this case behavioral), and \==" is a built-in operation that compares two terms, returning true i their normal forms are equal. Because all operations in this paper are either behavioral or else behaviorally congruent, ordinary equational deduction is sound, so that computations could be done in a non-behavioral mode, e.g., by OBJ3 [16]. open SET-BASIC . vars B B' : Bool . eq not (B or B') = not B and not B' . op e : -> Elt . ops s s' s'' : -> Set . red e in (s - s') - s'' == e in s - (s' U s'') . eq e in s = false . op e' : -> Elt . eq e eq e' = false . red e in ((s U s') - feg) == e in (s U (s' - feg)) . red e' in ((s U s') - feg) == e' in (s U (s' - feg)) . close

Therefore the speci cation below is indeed a protecting extension of SET-BASIC, as indicated by the notation \pr(SET-BASIC)"; note that \assoc" and \idem" respectively assert the associative and idempotent equations, in this case behaviorally, because of \bop". mod* SET f pr(SET-BASIC) bop _U_ : Set Set -> Set fcomm assoc idemg var E : Elt vars S S' S'' : Set beq (S - S') - S'' = S - (S' U S'') . bceq (S U S') - fEg = S U (S' - fEg) if not E in S . g

We now discuss closures. The usual de nition is a function on a powerset, C : P (X ) ! P (X ), that is extensive, monotone and idempotent. This is a standard way to axiomatize logical deduction, where C (A) is the set of all sentences that can be deduced from axioms in A [26]. But if elements in X are possible messages with dependencies among them, and if closure recurrently adds new dependent messages until stability is achieved, then the traditional closure is inappropriate, because it assumes knowing all possible messages, 9

Goguen and Rosu

whereas the universe of messages for a given site is all messages received there, which could be a small part of all messages exchanged among all sites. To handle such examples, we relativize closure to subsets of a universe: De nition 3.1 Given a set X , an X -indexed closure operator is an X indexed family of functions C = fCX : P (X ) ! P (X ) j X  Xg with the following properties, for all X  X :  Extensive: A  CX (A) for all A  X ,  Monotone: CX (A)  CX (B ) for all A  B  X ,  Idempotent: CY (CX (A)) = CY (A) for all A  X  Y . For another example, if X is all formulae over all signatures, and X is all formulae over a certain signature, then for any A  X , called a \presentation," CX (A) is the set of all formulae that are consequences of A, called the \theory of A." Many further examples can be adapted from indexed categories [25]. Proposition 3.2 C = fCX : P (X ) ! P (X ) j X  Xg is an X -indexed closure operator if and only if each CX is a closure operator such that CX (A)  CY (A) for all A  X  Y . Proof. If C is an X -indexed closure, then letting Y = X in the idempotence law gives CX (CX (A)) = CX (A), which is the (usual) closure idempotence; therefore CX is a closure operator for all X  X . Moreover, by extensivity and idempotency, CX (A)  CY (CX (A)) = CY (A). For the converse, we only need to show idempotence. By the extensivity and monotonicity of closure, CY (A)  CY (CX (A)). But because CX (A)  CY (A), monotonicity and idempotency give CY (CX (A))  CY (CY (A)) = CY (A), so that CY (CX (A)) = CY (A). 2 We now introduce some notation for use in our weaker behavioral speci cation of closure. If C is an X -indexed closure, de ne two functions from P (X )  P (X ) to P (X ) by:  L R is the set CL[R (L),  R ! L is the set R ? (L R), where L and R are any subsets of X . Intuitively, L R is the closure of L built using elements from R, and R ! L is the elements in R that are not in this closure of L. Note that because L  (L ! R), we have that R ! L = (L [ R) ? (L R). Then Proposition 3.3 The following equalities hold for any subsets L; R; R0 of X : (i) (L R) ((R ! L) [ R0) = L (R [ R0 ), and (ii) ((R ! L) [ R0 ) ! (L R) = (R [ R0) ! L. Proof. Notice that (L R) [ (R ! L) = L [ R. Then equality (i) translates to CL[R[R (CL[R(L)) = CL[R[R (L), which is true by the idempotence 10 0

0

Goguen and Rosu

of the indexed closure operator. Since R ! L = (L [ R) ? (L ! R), equality (ii) becomes (L [ R [ R0 ) ? ((L R) ((R ! L) [ R0)) = (L [ R [ R0 ) ? (L (R [ R0 )), which is true by (i). 2 These two properties plus extensivity are enough for the rest of this paper, and we call the resulting notion weak closure, for which the following is a behavioral speci cation: mod* WK-CLOSURE f pr(SET) bops (_-->_) (_ Set vars L R R' : Set var E : Elt bceq E in (L L . g

This notion of weak closure is strictly weaker than set-indexed closure, which means that it has more models. Because the protocol described in Section 4 is parameterized by weak closures, it admits more instances than if it were parameterized by set-indexed closures; in particular, non-monotonic logics are allowed, because monotonicity is not required by weak closure.

4 The Abstract Protocol This section speci es our protocol at a rather abstract level, and then proves some results about it. This protocol, or perhaps we should say, protocol design, is very general, in that it will transmit any data with dependencies structured as a weak closure; no form of centralization for control or data is in any way assumed. The following section describes a model of this speci cation, the tatami protocol for distributed cooperative proving [10], where the closure operator is a (relativized) deductive closure. The design assumes that lower layers implement daemons to physically send messages over the net, using still lower layers such as tcp/ip. To achieve exibility, we parameterize by a simple USER speci cation which only distinguishes users, and therefore only has an equality predicate, assumed re exive and symmetric (transitivity is not needed for our proofs). Here \QID" is a built in module de ning identi ers that begin with a quotation mark. mod* USER op name op _eq_ var U : eq U eq

f pr(QID) [ User ]

: User -> Id : User User -> Bool fcommg User U = true . g

The protocol speci cation is also parameterized, by users as well as by weak closures; thus it is fully de ned only when appropriately instantiated; Section 5 describes one such instantiation. mod* PROTOCOL(U :: USER, X :: WK-CLOSURE) f *[ State ]* bop Closed : State -> Set bop Zombies : State -> Set

11

Goguen and Rosu bop NotYetAck : State User -> Set var bop beq beq beq

S : State var E : Elt vars U U' : User insert : Elt State -> State Closed (insert(E,S)) = fEg U Closed(S) . Zombies (insert(E,S)) = Zombies(S) . NotYetAck(insert(E,S),U) = NotYetAck(S,U) .

bop submit : Elt State -> State beq Closed (submit(E,S)) = Closed(S) . beq Zombies (submit(E,S)) = Zombies(S) . bceq NotYetAck(submit(E,S),U) = fEg U NotYetAck(S,U) if E in Closed(S) . bop beq beq beq

receive : Elt State -> State Closed(receive(E,S)) = Closed(S) Closed(S) . NotYetAck(receive(E,S),U) = NotYetAck(S,U) .

bop beq beq beq

ack : User Elt State -> State Closed (ack(U,E,S)) = Closed(S) . Zombies (ack(U,E,S)) = Zombies(S) . NotYetAck(ack(U,E,S),U') = if U eq U' then NotYetAck(S,U) - fEg else NotYetAck(S,U') fi . g

Information can be extracted from the hidden sort, State, by the operations , , and NotYetAck, which return sets (also of hidden sort). gives all received messages (e.g., proof fragments) such that everything on which they depend has also been received; Zombies(S) gives the received messages that depend on other messages not yet received, due to the nondeterminism of the net; and NotYetAck(S,U) is the set of messages not yet acknowledged by user U. There are only four methods that change state:  The insert operation adds a new message provided all messages on which it depends are already received.  The submit method broadcasts a message (previously introduced by insert) to all users in the same project. It changes neither the completed messages nor the zombies of other users, but only adds its message to each collection of unacknowledged messages. (Lower layers should continue to send these messages until they are acknowledged.)  The receive operation is the most complex, since it involves closures. Because this operation can be called by lower layers, so-called upcalls 5 are allowed, with calls from user applications also allowed. When a new message is received, it is rst regarded as a zombie, and then a closure is formed. Closed Zombies Closed(S)

Usually, higher layers are clients of the services provided by lower layers, but sometimes lower layers need to notify higher layers of events, such as the arrival of a packet at the network interface. Clark [4] introduced \upcalls" as a way to structure internet and other protocols: higher layers pass handler operations to lower layers, to be called when the lower layer needs to notify the higher layer.

5

12

Goguen and Rosu

If the message depends on non-received but previously sent messages, then it stays a zombie until the missing messages arrive. On the other hand, if adding it to the closed messages results in a set that is still closed, it is also considered closed, is removed from the zombie list, and the remaining zombies are checked to see if they are closed. This process is repeated until stabilization is achieved 6 .  An ack (acknowledgment) for a message from a certain user changes only the state for that user. A familiar design problem for layered systems is that it may not be clear to which level some component belongs. We chose to place the ack operation at this level so that it can be called by user applications if an unreachable user unsubscribes, or if some messages no longer need to be acknowledged. Besides, it is interesting to specify and prove properties of it, which after all is a major goal of this paper. By Proposition 2.10 and Theorem 2.9,
= fClosed; Zombies; NotYetAckg is a cobasis for PROTOCOL. Therefore to prove that states S; S 0 are behaviorally equivalent, it suces to prove Closed(S ) = Closed(S 0), Zombies(S ) = Zombies(S 0 ), and NotYetAck(S; U ) = NotYetAck(S 0 ; U ) for each user U . 4.1 Consistency Consistency of protocols is dicult to formulate and dicult to prove. One important aspect of consistency that we will demonstrate here is that (under appropriate assumptions) losing messages, or receiving them out of order, does not eect what users see, nor do multiple receipts of the same message; these properties are respectively expressed as commutativity and idempotency properties of various operations for sending and receiving messages. 4.2 Commutativity of Operations This subsection considers when the operations that change state, insert, submit, receive and ack, give the same result regardless of their order. This is important for two reasons. First, we designed the protocol with these properties in mind, by gradually adding and re ning ingredients. Second, these are key properties for guaranteeing that user applications operate correctly. 4.2.1 Insert Insert operations commute because union is commutative. A rigorous proof would require three equations, as in the proofs below; we omit this for brevity. This motivated our set-indexed closure notion. Depending on the policy implemented, closure can mean anything from regarding all messages as closed, in which case there are no zombies and the protocol is connectionless, to regarding each message as depending on all previous messages, in which case the protocol behaves like an end-to-end connection. The most interesting cases, as in the tatami protocol, have some intermediate set of message dependencies.

6

13

Goguen and Rosu

Insert and submit operations do not always commute, because a recently inserted item can be submitted, but no item can be rst submitted and then inserted. Therefore the client should wait for an acknowledgment from the insert before sending the submit, if the communication between the client and the protocol is connectionless. However we expect each user to have a copy of the protocol and to communicate with it sequentially using remote procedure calls (RPCs), in which case this problem does not arise. An interesting solution for a client who prefers communication by messages instead of RPCs, would be to keep two instances of the protocol, for commands and for data. On the other hand, if the inserted and the submitted items are distinct and the submitted item is closed, then these operations do commute, because the reductions below all give true. open PROTOCOL . ops e1 e2 : -> Elt . op s : -> State . op u : -> User . eq e2 in Closed(s) = true . ** assume the submitted message is closed bred Closed (insert(e1,submit(e2,s))) == Closed (submit(e2,insert(e1,s))) . bred Zombies (insert(e1,submit(e2,s))) == Zombies (submit(e2,insert(e1,s))) . bred NotYetAck(insert(e1,submit(e2,s)),u) == NotYetAck(submit(e2,insert(e1,s)),u) . close

In CafeOBJ [6], \red" indicates behavioral rewriting, which diers from standard term rewriting as follows: whenever a hidden redex is found, apply the rewrite rule when there are only congruent operations on the path from that redex to the root until a visible sort is found; but if no visible sort is found, the rule still applies if all operations on the path from the redex to the root are congruent. CafeOBJ's red implements the subrelation of this without the case when all operations on the path to the redex are congruent and there is no visible sorted operation on that path. We have used the bred syntax above, because full behavioral rewriting could be implemented in place of CafeOBJ's currently unsound bred; more detailed discussion can be found in [23]. Insert and receive also fail to commute, because a received item e2 might depend on an inserted item e1, in which case receive(e2,insert(e1,s)) would deliver e2 because e1 is already closed, but e2 would be a zombie for insert(e1,receive(e2,s)). We see two solutions to this problem. The rst is to convince or force clients to only change items with the submit command; then an item depending on an inserted item can never be received before the inserted item. The other solution is to implement the insert command in a similar fashion to the receive command, that is, to rst regard the inserted item as a zombie and then execute a closure; but this solution seems to reduce user application exibility too much. In any case, if the received item does not depend on the inserted item, that is, if adding e1 is still closed, then the two operations do commute: open PROTOCOL . ops e1 e2 : -> Elt . op s : -> State . op u : -> User . beq (fe1g U Closed(s)) Closed(s) . red Closed (insert(e1,receive(e2,s))) red Zombies (insert(e1,receive(e2,s))) == Zombies (receive(e2,insert(e1,s))) . red NotYetAck(insert(e1,receive(e2,s)),u) == NotYetAck(receive(e2,insert(e1,s)),u) . close

The commutativity of insert and acknowledgment operations requires a case analysis on the acknowledger: open PROTOCOL . op e1 e2 : -> Elt . op s : -> State . ops u u' u'' : -> User . red Closed (insert(e1,ack(u,e2,s))) == Closed (ack(u,e2,insert(e1,s))) . red Zombies (insert(e1,ack(u,e2,s))) == Zombies (ack(u,e2,insert(e1,s))) . eq u eq u' = true . eq u eq u'' = false . red NotYetAck(insert(e1,ack(u,e2,s)),u') == NotYetAck(ack(u,e2,insert(e1,s)),u') . red NotYetAck(insert(e1,ack(u,e2,s)),u'') == NotYetAck(ack(u,e2,insert(e1,s)),u'') . close

4.2.2 Submit Submit operations commute with insert and receive operations, provided the submitted item is closed; also two submit operations commute if both submitted items are closed. The proofs are similar to those above. open PROTOCOL . ops e1 e2 : -> Elt . op s : -> State . ops u u' u'' : -> User . eq e1 in Closed(s) = true . eq e2 eq e1 = false . red Closed (submit(e1,ack(u,e2,s))) == Closed (ack(u,e2,submit(e1,s))) . red Zombies (submit(e1,ack(u,e2,s))) == Zombies (ack(u,e2,submit(e1,s))) . eq u eq u' = true . eq u eq u'' = false . red NotYetAck(submit(e1,ack(u,e2,s)),u') == NotYetAck(ack(u,e2,submit(e1,s)),u') . red NotYetAck(submit(e1,ack(u,e2,s)),u'') == NotYetAck(ack(u,e2,submit(e1,s)),u'') .

Notice that the two items are assumed distinct, and that the submitted message is assumed closed. 4.2.3 Receive and Acknowledge Receive and/or acknowledgment operations always commute, which means that the nondeterministic order in which messages travel over the internet does not behaviorally eect the state of the protocol. open PROTOCOL . ** receive - receive

15

Goguen and Rosu ops e1 e2 : -> Elt . op s : -> State . ops u u' u'' : -> User . red Closed (receive(e1,receive(e2,s))) == Closed (receive(e2,receive(e1,s))) . red Zombies (receive(e1,receive(e2,s))) == Zombies (receive(e2,receive(e1,s))) . red NotYetAck(receive(e1,receive(e2,s)),u) == NotYetAck(receive(e2,receive(e1,s)),u) . ** receive - ack red Closed (receive(e1,ack(u,e2,s))) == Closed (ack(u,e2,receive(e1,s))) . red Zombies (receive(e1,ack(u,e2,s))) == Zombies (ack(u,e2,receive(e1,s))) . red NotYetAck(receive(e1,ack(u,e2,s)),u) == NotYetAck(ack(u,e2,receive(e1,s)),u) . ** ack - ack red Closed (ack(u,e1,ack(u',e2,s))) == Closed (ack(u',e2,ack(u,e1,s))) . red Zombies (ack(u,e1,ack(u',e2,s))) == Zombies (ack(u',e2,ack(u,e1,s))) . ** there are 8 cases, but only one is treated here eq u eq u' = false . eq u eq u'' = false . eq u' eq u'' = true . red NotYetAck(ack(u,e1,ack(u',e2,s)),u'') == NotYetAck(ack(u',e2,ack(u,e1,s)),u'') . close

4.3 Idempotence If a user is disconnected for a long time, or if the network is very slow or is down, then a submitted message may be physically sent many times before an acknowledgment is received. This means that a message can be received many times, and an acknowledgment must be sent for each copy received to ask the sender stop sending that message. Also, if the communication between client and protocol is by messages, a similar situation might appear when sending insert and submit commands. As a result, the same message may be inserted, submitted, received and/or acknowledged many times. This trouble can be resolved at lower levels, for example at the daemon level, where messages are stamped and hence easy to recognize; but we do not want to prevent clients from working at higher levels when a certain site is not reachable. For this reason, we allow the protocol to handle multiple copies, and we prove that the operations are behaviorally idempotent. Only receive and acknowledge are treated here, the others being easier: open PROTOCOL . op e : -> Elt . op s : -> State . ops u u' u'' : -> User . ** receive - receive red Closed (receive(e,receive(e,s))) == Closed (receive(e,s)) . red Zombies (receive(e,receive(e,s))) == Zombies (receive(e,s)) . red NotYetAck(receive(e,receive(e,s)),u) == NotYetAck(receive(e,s),u) . ** ack - ack

16

Goguen and Rosu red Closed (ack(u,e,ack(u,e,s))) == Closed (ack(u,e,s)) . red Zombies (ack(u,e,ack(u,e,s))) == Zombies (ack(u,e,s)) . eq u eq u' = true . eq u eq u'' = false . red NotYetAck(ack(u,e,ack(u,e,s)),u') == NotYetAck(ack(u,e,s),u') . red NotYetAck(ack(u,e,ack(u,e,s)),u'') == NotYetAck(ack(u,e,s),u'') . close

5 The Tatami Protocol This section describes the tatami protocol as an instantiation of the abstract protocol of Section 4. Although this protocol was designed for the Kumo proof assistant and website generator [10,11], it was not actually implemented, because it was easier for Kumo to handle communication over an end-toend connection provided in the Java API, whereas the tatami protocol sends proofs, speci cations, inference rules, goals, etc. in smaller pieces. 5.1 Structure of Database Elements We let the word \element" refer to any item that can be stored in the database used by the protocol. These database elements have nine elds. The rst eight are included in transmitted messages, while the nal boolean eld is only used locally. We now brie y describe the meaning of each eld: 1. A unique name (or \tag") is generated whenever an element is inserted into the database. One way to the guarantee uniqueness of these names is to keep a local counter which is incremented whenever an element is inserted, and then assign the name huser id i.hcounter i to that element. 2. Elements have a type, which is one of speci cation, inference rule, proof task, subproof. Elements are treated dierently depending on their type (see the case analysis appearing in the pseudo-code for Receive below). 3. The parent list is a list of tags, the meaning of which depends on the type of the element. If it is a speci cation, then the parent list contains names of speci cations from which the given speci cation evolved; these names are not needed by the protocol, but may be useful to users; for example, it has been noticed that in many examples, speci cations are changed more often than proofs. If the element is an inference rule, then the parent list contains names of rules on which the given rule depends (noting that Kumo allows users to de ne new rules from existing rules). A rule cannot be delivered unless all its parents have been delivered. If the element is a proof task, then the parent list contains the names of subproofs using that proof task as a leaf. A proof task will not be delivered unless at least one of its parents is already delivered; this policy avoids having ghost nodes in proofs. We also considered another policy, requiring that all of a proof task's parents be delivered, but it seems too strong. If the given element is a subproof, then its parent list contains only one name, that of its proof task. Of course, a subproof cannot be delivered 17

Goguen and Rosu

unless its parent is delivered. 4. A fuzzy value in the unit interval is attached to each proof task and subproof. These values are updated by the truth maintenance procedure whenever a new element is inserted in the database. The fuzzy value of a proof task is the maximum of the fuzzy values of the subproofs that support it. The fuzzy value of a subproof is calculated from the fuzzy values of its leaves, by evaluating the associated boolean formula (see 5. below), taking or as maximum and and as product [7]. The use of fuzzy truth values corresponds to the reality of software engineering, where complete formal veri cation is rarely performed, but rather various levels of assurance are obtained by a variety of means, including testing, back-of-envelope calculations, proof sketches, simulations, and informal arguments; fuzzy truth values can be used to prioritize such tasks when a bug is found, or if a greater level of assurance is desired. 5. A boolean formula is associated with each subproof; other types of elements do not need it. This formula gives the truth value of the root in terms of the truth values of the leaves; it is evaluated when the subproof is created, and is also used by the truth maintenance procedure when updates occur. 6. The owner of an element is the only user authorized to delete that element. If someone else in the project uses the name of that element (which can be checked by consulting its parent list), then that user becomes the new owner of that element (which is not physically deleted). We do not discuss deletion in the present paper, but see [10]. 7. Kumo builds web pages from the elements in the database. Once the web pages are created for (the closure of) an element, Kumo asks the protocol to add a new URL to the URL list for that element. This \update" message is broadcast, so that users will not delete these pages, because deletion should only be done using Kumo or some other client which asks the protocol to broadcast the update. 8. The auxiliary information eld can contain anything the user wants to associate with an element, such as an explanation for a proof, an applet, or a movie. 9. The local bit distinguishes between local and global elements. It is true i that element has been submitted to the rest of the project. 5.2 Pseudo-code The tatami protocol has some operations beyond those speci ed in the abstract protocol. These are described below, using the notation ) indicate insertion of an element into, or deletion from, a class, depending on the order of its arguments, and the notation to indicate assignment, as usual. 1) Get name generates a new unique name; this operation is called by Kumo 18

Goguen and Rosu

when a new element is inserted to the database: Get name()

counter

counter + 1

return huser idi.hcounteri

2) Delivered(hnamei) tells whether the element hnamei is in the database. 3) Because of the parent list associated to each element, the database can be

viewed as a dag 7 . Closure gives all the elements in the subdag rooted in a certain element; it can be implemented in linear time. 4) Insert adds an element to the database and sets its local bit; the client should rst get a new name for the element. Insert(element e) e:local yes e ) Closed 5) Submit clears the local bit and asks a daemon to physically broadcast the element; an interesting and useful variant submits all local elements in the closure of a certain element: Submit(element e) if not Delivered(e:name) then return for all e0 2 Closure(e) do if e0 :local then (e0 :local no; broadcast(e0 )) 6) The Receive operation is upcalled by the receiver daemon whenever an element is received. Receive(element e) e ) Zombies if not Parents ok(e) then return Deliver(e)

while (not stable) do

stable true for each e0 2 Zombies do if Parents ok(e0) then Deliver(e0 )

The auxiliary operations Parents ok and Deliver are de ned as follows: Parents ok(element e) case e:type of speci cation : return true \Dag" is an abbreviation for directed (ordered) acyclic graph; see [10] for further discussion of proof dags.

7

19

Goguen and Rosu

inference rule : if (8n 2 e:parents) Delivered(n) then return true subproof, proof task : if (9n 2 e:parents) Delivered(n) then return true return false Deliver(element e)

Zombies ) e ) Closed stable false

update fuzzy values along the path(s) from e to the root

Thus, this protocol initially regards a received element as a zombie. If it cannot be delivered because the parent condition fails, then it returns; otherwise, the element is delivered, and the algorithm checks for other zombie elements that can now be delivered. The Parents ok operation does a case analysis on the element's type: a speci cation does not depend on its parents; a rule depends directly on all its parents; a subproof depends only on its (unique) proof task, and a proof task is ok only if one of its parents is already delivered. The deliver operation inserts a zombie into the database and then modi es the fuzzy truth values of the nodes above it in the proof dag.

6 Conclusions The approach of this paper has been dierent from that of a correctness proof by behavioral re nement; in particular, we have exploited behavioral parameterization, rather than behavioral satisfaction, to explicate the relation between the abstract and the concrete versions of the protocol, and we have given only an informal description of the concrete tatami protocol, rather than a formal behavioral speci cation. However, a full correctness proof would require such a speci cation, in addition to a formal speci cation of the appropriate weak closure operator to serve as parameter. From an application point of view, the most novel aspect of our abstract broadcast protocol is the very general way that it is parameterized by dependencies among messages, allowing even non-monotonic dependencies; for the concrete tatami protocol, the use of fuzzy truth values for boolean formulae is interesting, in addition to the way that dependencies are handled. From a technical point of view, the most novel aspect is our de nition and use of weak closures, but from the methodological point of view, it is our use of behavioral parameterization. The idempotent and commutative proofs for the abstract protocol are also of methodological interest, because the importance for protocols of these simple mathematical properties seems not to have been previously recognized, possibly because in general they are only behaviorally satis ed by implementations, rather than strictly satis ed. Finally, we wish to note that this rather non-trivial example underlines the importance of several recent augmentations to hidden algebra, including behavioral rewriting, multiple hidden arguments, congruent operations, the congruence criterion, cobases, and
-coinduction. 20

Goguen and Rosu

References [1] Gilles Bernot, Michael Bidoit, and Teodor Knapik. Observational speci cations and the indistinguishability assumption. Theoretical Computer Science, 139(12):275{314, 1995. Submitted 1992. [2] Michael Bidoit and Rolf Hennicker. Behavioral theories and the proof of behavioral properties. Theoretical Computer Science, 165:3{55, 1996. [3] Michael Bidoit and Rolf Hennicker. Observer complete de nitions are behaviourally coherent. Technical Report LSV-99-4, Ecole Normale Superior de Cachan, 1999. [4] David Clark. The structuring of systems using upcalls. SIGOPS (Special Interest Group on Operating Systems), 19(5):171{180, December 1985. [5] Razvan Diaconescu. Behavioural coherence in object-oriented algebraic speci cation. Technical Report IS{RR{98{0017F, Japan Advanced Institute for Science and Technology, June 1998. Submitted for publication. [6] Razvan Diaconescu and Kokichi Futatsugi. CafeOBJ Report: The Language, Proof Techniques, and Methodologies for Object-Oriented Algebraic Speci cation. World Scienti c, 1998. AMAST Series in Computing, Volume 6. [7] Joseph Goguen. The logic of inexact concepts. Synthese, 19:325{373, 1968{69. [8] Joseph Goguen. Types as theories. In George Michael Reed, Andrew William Roscoe, and Ralph F. Wachter, editors, Topology and Category Theory in Computer Science, pages 357{390. Oxford, 1991. Proceedings of a Conference held at Oxford, June 1989. [9] Joseph Goguen and Razvan Diaconescu. Towards an algebraic semantics for the object paradigm. In Hartmut Ehrig and Fernando Orejas, editors, Proceedings, Tenth Workshop on Abstract Data Types, pages 1{29. Springer, 1994. Lecture Notes in Computer Science, Volume 785. [10] Joseph Goguen, Kai Lin, Akira Mori, Grigore Rosu, and Akiyoshi Sato. Distributed cooperative formal methods tools. In Michael Lowry, editor, Proceedings, Automated Software Engineering, pages 55{62. IEEE, 1997. [11] Joseph Goguen, Kai Lin, Akira Mori, Grigore Rosu, and Akiyoshi Sato. Tools for distributed cooperative design and validation. In Proceedings, CafeOBJ Symposium. Japan Advanced Institute for Science and Technology, 1998. Namazu, Japan, April 1998. [12] Joseph Goguen and Grant Malcolm. Programs. MIT, 1996.

Algebraic Semantics of Imperative

[13] Joseph Goguen and Grant Malcolm. A hidden agenda. Theoretical Computer Science, to appear. Also UCSD Dept. Computer Science & Eng. Technical Report CS97{538, May 1997.

21

Goguen and Rosu

[14] Joseph Goguen and Grigore Rosu. Hiding more of hidden algebra. In FM'99 { Formal Methods, pages 1704{1719. Springer, 1999. Lecture Notes in Computer Sciences, Volume 1709, Proceedings of World Congress on Formal Methods, Toulouse, France. [15] Joseph Goguen, James Thatcher, and Eric Wagner. An initial algebra approach to the speci cation, correctness and implementation of abstract data types. In Raymond Yeh, editor, Current Trends in Programming Methodology, IV, pages 80{149. Prentice-Hall, 1978. [16] Joseph Goguen, Timothy Winkler, Jose Meseguer, Kokichi Futatsugi, and JeanPierre Jouannaud. Introducing OBJ. In Joseph Goguen and Grant Malcolm, editors, Software Engineering with OBJ: Algebraic Speci cation in Action. Kluwer, to appear. Also Technical Report SRI-CSL-88-9, August 1988, SRI International. [17] Rolf Hennicker and Michel Bidoit. Observational logic. In Algebraic Methodology and Software Technology (AMAST'98), volume 1548 of Lecture Notes in Computer Science, pages 263{277. Springer, 1999. [18] Bart Jacobs and Jan Rutten. A tutorial on (co)algebras and (co)induction. Bulletin of the European Association for Theoretical Computer Science, 62:222{ 259, June 1997. [19] Michihiro Matsumoto and Kokichi Futatsugi. Test set coinduction { toward automated veri cation of behavioral properties. In Proceedings of the Second International Workshop on Rewriting Logic and Its Applications (WRLA'98), volume 15 of Electronic Notes in Theoretical Computer Science. Elsevier Science, 1998. [20] Peter Padawitz. Swinging data types: Syntax, semantics, and theory. In Proceedings, WADT'95, pages 409{435. Springer, 1996. Lecture Notes in Computer Science, Volume 1130. [21] Peter Padawitz. Towards the one-tiered design of data types and transition systems. In Proceedings, WADT'97, pages 365{380. Springer, 1998. Lecture Notes in Computer Science, Volume 1376. [22] Horst Reichel. Behavioural equivalence { a unifying concept for initial and nal speci cations. In Proceedings, Third Hungarian Computer Science Conference. Akademiai Kiado, 1981. Budapest. [23] Grigore Rosu. Behavioral coinductive rewriting. In Kokichi Futatsugi, Joseph Goguen, and Jose Meseguer, editors, OBJ/CafeOBJ/Maude at Formal Methods '99, pages 179{196. Theta (Bucharest), 1999. Proceedings of a workshop held in Toulouse, France, 20th and 22nd September 1999. [24] Grigore Rosu and Joseph Goguen. Hidden congruent deduction. In Ricardo Caferra and Gernot Salzer, editors, Proceedings, 1998 Workshop on First Order Theorem Proving, pages 213{223. Technische Universitat Wien, 1998. (Schloss Wilhelminenberg, Vienna, November 23-25, 1998). Full version to appear in Lecture Notes in Arti cial Intelligence, Springer, 1999.

22

Goguen and Rosu

[25] Andrzej Tarlecki, Rod Burstall, and Joseph Goguen. Some fundamental algebraic tools for the semantics of computation, part 3: Indexed categories. Theoretical Computer Science, 91:239{264, 1991. Also, Monograph PRG{77, August 1989, Programming Research Group, Oxford University. [26] Alfred Tarski. On Some Fundamental Concepts of Metamathematics, pages 30{37. Oxford, 1956.

23