A pi-calculus Semantics for an
Object-Based Design Notation
C. B. Jones
Department of Computer Science
Manchester University, M13 9PL, UK
[email protected], ac.uk
A b s t r a c t . Companion papers give examples of the development of concurrent programs using a design notation which employs a number of concepts
from object-oriented programming languages. This paper documents the semantics of the design language by providing a mapping to the pi-calculus.
1 Introduction
It has long been realized that restrictions on programming languages are key to
the development of concurrent programs. Both [Jon93a, Jon93b] use object-based
concepts to facilitate the development of concurrent programs: the former uses constraints on the objecl graphs to limit interference; the latter employs assertions to
reason about about interference.
The design language used in the above referenced papers is known as ~ro~A. The
7roflA class presented in Figure 1 provide s a sorting facility. Each instance of the
class has two instance variables. The variable v contains the natural number which
is stored in one element of the class and the variable l - if not nil - contains a
reference to another instance of this class. By tracing along this series of references,
one can collect the sorted sequence of values from the v variables. The class - and
thus each of its instances - has three methods. The add method accepts a non-zero
natural number and stores it at an appropriate place in the sequence of instances;
the remove method returns the first (i.e. lowest) element o f the sequence; and the
lesl method determines whether a given natural number is or is not in the sorted
vector (for simplicity, zero is used to mark a nil value). The semantics of ~ro~A is
such that only one method can be active in any one instance of a class at a time.
The code which invokes a method is held in a rendezvous until the m e t h o d being
executed reaches a return statement. Notice that the add method contains a return
as its first statement so, as soon as the parameter has been passed, the caller is
released from the rendezvous. The remainder of the code of the add method does
what one might expect: the higher value is passed down a chain of method-calls
linked by the I instance variables. Because of the way the returns work, concurrency
is possible within a sequence of instances of the Sort class. The only other point
in add is to notice that when the first value is stored in an instance of the class, a
new next item is created in the linked-list. The remove method is similar, noting
only t h a t it destroys the final element of the linked-list of instances when a zero
is passed back from further down the list. The idea of obtaining concurrency by
making sure that returns are executed as soon as possible would also be useful in
159
t h e lest method. But, here the invoking procedure is b o u n d to be held up because
a value is required. The effect of the yield s t a t e m e n t in lesl is to delegate the task
of returning a value but to terminate this instance of the test m e t h o d so t h a t other
m e t h o d s can be invoked on the same instance of the class.
Sort class
vars v: [N] *-- O; h private ref(Sort) *-- nil
add(x: 1~1) method
return
if v = 0 then (v .-- x; I ~ new Sort)
elif v < x then l!add(x)
else (t!add(v); v -- x)
fi
rein 0 method r: N1
return v
if v ~ 0 then v ~ l!rem 0
if v = 0 then l *-- nll fi
fi
test(x: I~1) method r:
if x = v then return true
elif v = 0 V x _< v then return false
else yield l!test(z)
fi
F i g . 1. Example program Sort
It is worth noting t h a t the specification of the Sort class in Figure 1 is by no
m e a n s trivial. It is not possible to write a conventional p r e / p o s t - c o n d i t i o n specification because the initial state to which one m i g h t expect to relate the finM s t a t e
in a post-condition is in fact a composite of the values stored in the v variables
a n d any activity of add and remove operations which is still rippling down the list.
It would be necessary in order to write such a specification to use something like
L a m p o r t ' s 'prophecy variables'. The text presented in Figure 1 is a c t u a l l y developed
in [Jon93a] via a sequential (i.e. non-concurrent) version of the s a m e algorithm. T h e
sequential version differs from that presented in Figure 1 b y having the r e t u r n statem e n t s placed at the end of add and remove m e t h o d s and the yield s t a t e m e n t in test
w r i t t e n as a return. The sequential p r o g r a m is easy to specify and to develop by
n o r m a l concepts of d a t a reification and operation decomposition; the final concurrent code presented in Figure 1 is derived by a step of t r a n s f o r m a t i o n . Of course~
it is necessary to know that such transformation rules are correct in the sense t h a t
t h e y preserve the intended behaviour of the m e t h o d s of the class; in other words
it is necessary to show under what circumstances it is valid to p e r m u t e the return
s t a t e m e n t s in methods and to substitute yield s t a t e m e n t s for r e t u r n s t a t e m e n t s .
A l t h o u g h presented as a program it is ~aot the intention t h a t 7ro/3~ be seen as a
new concurrent object-oriented p r o g r a m m i n g language. It would certainly be simpler
to use ~rofl)~ as a design notation and to i m p l e m e n t the p r o g r a m s in some language
160
such as POOL, Beta, Modula-3 or ABCL. But it is necessary to fix the semantics
of ~roflA in much the same way as one would describe the formal semantics of a
programming language in order to justify proof obligations and transformation rules
which are to be used in the development method.
A denotational semantics would have to deal with concurrency (relevant papers
include [Wo188, AR89, AR92, dBdV91]). In some respects, a semantics based on
resumptions fits this sort of parallel object-based language quite well but there are
some difficulties and these would even be shared by an operational semantics. The
core of the problem - in such a model-oriented semantics - seems to be that it is
necessary to describe a very fine level of granularity in order to prove that this level
of granularity does not actually make any difference. The approach followed in the
current paper is to map the constructs of ~ro~A to the w-calculus [MPW92, Mil92b].
It would be possible to argue that this semantics is also giving too fine a level of
granularity but in this case the ~r-calculus has an algebra which makes it easy to
reason about equivalencies between processes.
Section 2 of this paper describes the basic ideas of mapping 7roflA into the ~'calculus; the problem of handling instance variables and the special case of those
instance variables containing references is discussed in Section 3. The task of showing
that certain transformations are correct is addressed in Section 4. Some detailed
problems of the mapping are described in Section 5 and the mapping is summarised
in Appendix B. The version of the 7r-calculus used is described in Appendix A and
the paper contains a discussion in Section 6.
2
Basic mapping
This section (together with Sections 3 and 5) develops a mapping from ,'roflA to
the version of the polyadic ~r-calculus given in Appendix A. In the spirit of Peter
Landin's [Lan66] - 7r-calculus equivalents of increasingly complex ~ro~A texts are
considered; a complete mapping function ([.]) is given in Appendix B.
2.1
R e p r e s e n t i n g B o o l e a n values
Just as in the A-calculus, values such as Booleans and integers have to be constructed
from the raw 7r-calculus. Here, processes are given for the Boolean values and expressions. The basic idea is simple - for example true located by some name b can
be represented as b(lf).7. So if Vb then P else Q could be represented as
(v~f)(blf.(l().P
-b f().Q))
The process located at b is, however, ephemeral in that it can only be used once;
replication can be employed to provide Boolean values.
def
Boo/=
! b,(g).71
! b1(g).7
This is a process which is run in parallel with the meaning of a family of classes
and makes available names (bt, hi) for the two Boolean values. These values are
161
immutable. Evaluation of (Boolean) expression [e]l locates the name of the appropriate Boolean value at I; thus, for example
[true]/= lbt
[false]]/= lb 1
[c ^ d]l = (,11h)([r
I [d]/2 b Iz(bz).(L'ff)(~ff .(q).12(b2).Tb=
+10.Tbf)))
Notice that this coding relies on the fact that there are a finite number of Boolean
values thus allowing (finite) sums to be used to distinguish values. This is one reason
for handling natural numbers as 7ro/3A classes in Section 3.2. (Access to variables,
and assignment, are postponed to Section 3.1.)
2.2
S i m p l e classes
Consider the simple ro3A class definition
C class
ml(x) method return
m20 method r: ref return self
The semantics must show that multiple instances of C can be created. This is modelled by replication to provide an unbounded resource
def
[C] = l i e
(1)
A private name (u) is passed on some channel c (it is assumed that a static association will be made of names like c to class names like C). Because of the ( v u ) ( . . . )
the name is distinct for each instance.
Sc = (=,u)(~u.B,)
(2)
The creation of new instances of C (new C) can be mapped to
c(u).
9 9 - ~(...)...
The name u can be seen as a 'capability'l; the naming rules of the 7r-calculus ensure
that different instances of C do not interfere with each other; interference can only
occur when the owner of the name u shares it between parallel threads. So, the
model of each instance is (with Bu used recursively at the end of either method)
B, = .-..My
My = ( c q ( . . . ) . . . . B , + a 2 ( . . . ) . - . . B u )
The selection of methods is handled by passing two start names (cq,~2) to the
invoking process so that it can use the appropriate one. The ellipses above are
completed as follows.
hi= = ( az (wz z ).~.B= Jr a2(w2 ).~-~u.B, )
(3)
1 On page 56 of 'Time Sharing Computer Systems' (MacDonald/Elsevier 1968), Maurice
Wilkes attributes the term capability to Van Horn (1966) in 'Computer design for asynchronously reproducible multiprocessing', MAC-TR-34, M.I.T.
162
As well as any argument (e.g. z to mx), each start name carries a termination name
(wi) which is used to signal the end of the rendezvous. So the method call u!ml(e)
is mapped to
and u!m20 is mapped to
u(~1~2).(~'~2)(~.~2(u'))
The mapping [C] gives the semantics for class C in the sense that the behaviour
as seen by invoking expressions which are also mapped via [.] must be reproduced
by any implementation.
3
Handling instance variables
The preceding section has given the basic idea of the mapping but there is little real
interest in classes which contain no local state. This section reviews what changes in
the mapping are necessary when instance yariables are added to classes and moves
on to review the case where these instance variables can contain references.
Var class
vars v : B *-- false
w ( x : B ) method v *-- x; return
r 0 method return v
Fig. 2. Example program Var
3.1
Boolean instance variables
Consider the class Vat in Figure 2. It has methods which write (w) and read (r)
an instance variable (v) which contains Boolean values. This can be modelled as in
Equations 1 to 3 with an additional stateful process (Vy) for each instance variable.
(The instance variable itself is like a class for which only one instance is required;
this degenerate class has methods for access (a~) and setting (s~) whose interface is
simple because they can only be invoked from one place.)
[ Var] dof
= ! Ivar
B, = ( u f f ) ( ~ . M , )
M~ = (ato(wwz).'g-ffvz.~-'~.B=+ ar(wr).av(y).~'Ty.B~)
vy = (~u. v~ + s.(~), v~)
(4)
(5)
(6)
(7)
(8)
163
It is worth recording the SORTs for this definition:
c: C,u: U,c~,~: A~, c~r: Ar, w~: ~ ,
w~: ~ , s~: Sv, a~: A v
where
VAL), A~ ~ ( ~ ) , ~ . ~ O, ~ ~ (VAL),
& ~ (VAL),A~ ~ (VAL)
A~ ~ ( ~ ,
More generally, variable access and assignment are mapped as follows
[vF ~f a~(~).7~
[,, ,- el d~E(~O([e]l 1 l(b).~b)
3.2
R e f e r e n c e values
As indicated above, rofl~'s instance names are mapped to names in the r-calculus.
Instance variables which contain references store instance names just as those in
Section 3.1 contain the names of Boolean values. The only technicality which has
to be addressed is that the nll reference indicates an uninitialized reference. This
is handled here by using a completely private name ((~n)(Ln)) whose use wouId
cause the reductions to fail. (One could of course program some exception handling
mechanism for richer languages than ~rofl~.)
Rather than write out long ;r-calculus expressions, the natural numbers are presented by roflA classes whose mapping would yield the appropriate meaning.
Zero class
p: ref(Zero); v: r e f ( N a i )
new(z) method p ~-- self
Les~z0 method return true
succ0 m et ho d
vars
if v =
*-- nil
nil then v *-- new N a t ( s e l f ) fi
return v
pred0
method return p
Nat class
vars p: ref(Nal~); v: r e f ( N a ~ ) ~ - - n l l
new(z) method p *-- :c
testz0 method
succ0 m et ho d
return false
if v = nil then v *-- new N a t ( s e l f ) fi
return v
prcd0
method return p
Notice that Zero and Na~ have to be regarded as having the same type.
164
3.3
Yield statements
The yield construct is handled by passing on the name (say, wt) to which the method
containing the construct was to return its resfilt. Thus the test method of Figure 1
(which uses a yield statement) is mapped to
~o(~ox)..-. +~(~)....
+
M~=
(tO.S1
a,(~,~).am(m).b: = "d.
\fO.[[m
S1 = ~"~t[true].Bu
5'2 = DT[false].B.
S3 = az(u').u'(~/).a~,x.B~
Whereas,
test with a return statement would be mapped to
= al(u ).u (o~).(vwt)(o~twtx.wt(b)).wtb.B u
4
Transforming
(10)
statements
Section 5 addresses some details of the mapping which need to be understood before
the full mapping in Appendix B can be read. However, before going on to that,
enough material has been presented in order to consider the task of transformation
steps. Many simple transformations such as removing temporary variables could
be considered; in this paper attention is focused on transformations which affect
concurrency. The first example is the relatively simple case of moving a return where
no references are involved. Suppose the w method of Var (Figure 2) above were
transformed into
W(X:]~) m e t h o d
return ; v *--
X
Then it would be mapped to a ,v-calculus expression which only differs by the inversion of two prefixes: Mu of Equation 7 becomes
M" =
+...)
(11)
Consider the need to justify this transformation (i.e. showing that no ro/?A system can detect which version of Var is being used). A standard approach to equivalences in process algebras is to prove bi-similarity. Unfortunately, the two r-calculus
expressions from the two versions of the method are not bi-similar since the prefixes
can occur in different orders. Any claim of equivalence needs to reflect the context.
The approach here is to argue that the two expressions eventually reduce to the
same process. Specifically, suppose the using code
z,-.ew
w,'; z!w(t,oe); 9
t!r(); ...
165
is mapped to
Po "- c(u).P1
P1 = u(~,).P2
P2 = (w,o )('a-g~,~,obt.~,~() ).P3
Ps "- u(~).P4
P4 = (W~)(~r.Wr(Y)).P5
where u is not used in Ps- The fact that the distinction between My and M~ makes
no difference to the using code can be shown be a series of 7r-calculus reductions.
(Notice that the processes have been chosen to pun the names sent and received;
although this is convenient, it must be remembered that the names are actually
distinct. In fact, if the puns were not there one would have to use PAR steps.) The
composition of the invocation P0 with the denotation of the class is (the version of
the My process from Equation 7 is used first).
P0 I [Var] I Q
This reduces in a number of
I
I
GOMM
steps to
10
(12)
where, u is local to (P~ [(vsvao)(B~ ] Vb,)) (but Q could create its own instances
of Var). Continuing the reductions one arrives at
(vu)((vww)(ww().Pz [ (vSvav)(-g-~vbt.'&'-~w.Bu[ Vh))) [ !IVar [ O
(13)
This is the point at which the distinction between Equations 7 and 11 becomes
visible. Continuing the reductions in this case yields
(vu)(u(~).P4 l (us~a~)((v~)(-~.M,,) [ Vb,)) ]!Iv,,,-] O
(14)
Were the definition from Equation 11 used, Equation 13 would be
(uu)((w,~)(w,~(l.P3
l(vs,,a,,l(-m--g~.~bt.B,,
]V~,)))J!Iv,,.IQ
which reduces to
(vu)(u(~).P41(vs,,a,,)(~bt.B,,
I Vb,)) I !Iv=~ I Q
(15)
Intuitively it is easy to see that no further negative occurrence of u is available in
Equation 15 until after the recursion triggers a further instance of By; the reductions
continue to yield exactly Equation 14 except for the original distinction between B~
and B~. This shows that the specific transformation preserves equivalence in this
specific context. (Notice that [bt] has been assumed to be immutable.)
Of course, more general proofs are required. In the example with which the
paper began (Sort in Figure 1), the return statement is permuted with statements
which cause non-trivial concurrent activity via references. The proof of the general
transformation and a discussion of the yield transformation are tackled in [Jon94].
166
5
M o r e a b o u t composite statements
So far, the sequential order of 5'1; $2 has been modelled by prefixing the r-calculus
mapping of S1 to that of 5'2 (cf. Equation 7). This idea will not extend to the ease
5'1 has to be mapped to a composition. An alternative is to ensure that a completion
signal is sent from the r-calculus equivalent of 5'1 and to compose this with an
expression which is guarded by that prefix. So [$1; $2] signals termination on l by
I
Skip statements are modelled by
[SK,P] %f7.0
A conditional statement if e then Sl else s2 fi can then be modelled by
(vl'lll2)(BoolEval(l', 11, Is) I [e]l' J (lt().[sa]l--J- 12().[s2]l))
where
BoolEval(l', Ix, l~) ~f l'(b).'btf
I (/().~+f().~)
(16)
A while statement while e do sod can be modelled by the recursive equation
W =(r,l'lll2t')(Bools
I~, l~_)l[e]l'l(IK).[s]l"-{-/~0.7)I
t"(). W)
In [Jon93b], a parallel construct is used in the to/3,\ design notation. This is not
used in [3on93a] and is not considered in Appendix B but it could be mapped in
much the way that Milner discusses Section 8.3 of [Mi189].
6
6.1
Discussion
F u r t h e r work
As discussed in [Jon93a] some language issues remain to be resolved in ro/3A itself.
One radical alternative which might be considered is to follow the Smalltalk-80 idea
of getting by without a while statement and using block statements in the language.
This would obviate the need for the while statement as a primitive construct and in
some senses amounts to doing in rofl,\ what is already done here in the r-calculus.
Another idea for an extension to the r0]~,\ language is that it would be possible to
give path expressions as constraints on the order in which methods can be invoked
(for example a w must precede any sequence of w or r). As discussed in [Jon93a],
7ro/~A needs some extension in order to handle situations where methods cannot
necessarily be accepted. An obvious extension would be to add conditional method
accept but it might also be possible to add a suspend idea or indeed the whole
problem may be circumvented by some form of exceptions.
There is also further work to be done on the proofs. The examples of reductions above are specific examples where equivalences are preserved. It is intended
that [Jon94] will give general proofs of the transformations which are used for return and yield statements. It is furthermore necessary to do something about the
proof obligations which arise in [Jon93b]. It appears to be possible to add models
of methods which expose the values of instance variables so that assertions can be
'programmed' in a richer language than the programmer is allowed to use.
167
6.2
R e l a t e d work
The reader is referred to [MPW92, Mi192b] for notes on the history of the evolution
of process algebras which permit name passing. Milner discusses useful examples
of representing imperative languages in CCS already in [Mil89]. An early version of
the mapping contained in this paper was being worked on by the current author
when [Wal91] was sent to him. In that paper, Walker maps POOL to the monadic
version of the r-calculus but the paper had a stimulating effect on the mapping
being being done from ro/?A to the polyadic r-calculus and resulted in a number of
changes. A preliminary sketch of the mapping from ro/~A to the polyadic r-calculus
is given in [Jon92]. In [Wa193a], Walker, amongst other things, provides a mapping
from POOL to the polyadic r-calculus and this again had a stimulating effect on
the mapping provided here. Finally, [Wal93b] provides a mapping from ro/~A to the
higher-order r-calculus.
Other researchers who have provided semantics for object-oriented languages
based on process algebras include Honda and Tokoro [HW91b] (based on [nT91a])
and [Vaa90] (employs the process algebra known as ACP). Davide Sangiorgi's work
on the higher-order r-calculus [San93] provides strong arguments for using a higherorder calculus; the current author's concern is that the extra power of the higherorder calculus may make it more difficult to prove the sort of results which are
needed here. As is seen in [Wa193b], it is in fact only necessary to use a second-order
version of the r-calculus and even this is only really needed as a way of economising
on the notation needed to pass values. Another author who has investigated calculi
which are suitable for object-oriented programming languages is Oscar Nierstrasz.
His 'object calculus' in [Nie92] can be compared to the higher-order r-calculus.
Acknowledgements
The author is grateful for financial support from the SERC who fund his Senior
Research Fellowship.
Technical acknowledgements to people who have helped with the evolution of
r o ~ itself are contained in [Jon93a, Jon93b]. This paper has been specifically influenced by comments from Kohei Honda, Colin Stifling, Robin Milner, Davide Sangiorgi and above all by detailed reviews from David Walker. Valuable comments
have been received during seminars at IFIP WG 2.3, Oslo, Edinburgh and Geneva
Universities.
References
[Ame91] P. America, editor. ECOOP'91, volume 612 of Lecture Notes in Computer Science. Springer-Verlag, 1991.
[AR89] Pierre America and Jan Rutten. A Parallel Object-Oriented Language: Design
and Semantic Foundations. PhD thesis, Free University of Amsterdam, 1989.
JAR92] Pierre America and Jan Rutten. A layered semantics for a parallel objectoriented language. Formal Aspects of Computing, 4(4):376-408, 1992.
[Bae90] J. C. M. Baeten, editor. Applications of Process Algebra. Cambridge University
Press, 1990.
168
[dBdV91] J. W. de Bakker and E. P. de Vink. Rendez-vous with metric semantics. In
Proceedings o] the REX Workshop on Semantics: Foundations and Applications,
volume 506 of Lecture Notes in Computer Science. Springer-Verlag, 1991.
M-C. Gaudel and J-P. Jouannaud, editors. TAPSOFT'93: Theory and Practice
[GJ931
o] Software Development, volume 668 of Lecture Notes in Computer Science.
Sprlnger-Verlag, 1993.
[HT91a] K. Honda and M. Tokoro. An object calculus for asynchronous communication.
In [Ame91], pages 133-147, 1991.
[HT91b] K. Honda and M. Tokoro. A small calculus for concurrent objects. ACM, OOPS
Messenger, 2(2):50-54, 1991.
T. Ito and A. R. Meyer, editors. TAGS'91 - Proceedings o.f the International
JIM91]
Con]erence on Theoretical Aspects o] Computer Science, Sendal, Japan, volume
526 of Lecture Notes in Computer Science. Springer-Verlag, 1991.
[Jon92] C. B. Jones. An object-based design method for concurrent programs. Technical
Report UMCS-92-12-1, Manchester University, 1992.
[Jon93a] C. B. Jones. Constraining interference in an object-based design method. In
[GJ93], pages 136-150, 1993.
[Jon93b] C. B. Jones. Reasoning about interference in an object-based design method.
In FME'93: Industrial-Strength Formal Methods, volume 670 of Lecture Notes in
Computer Science, pages 1-18. Springer-Verlag, 1993.
[Jon94] C. B. Jones. Process algebra arguments about an object-based design notation.
In A. W. Roscoe, editor, Festschrift for Tony Hoare. Prentice-Hall, 1994,
[Lan66] P. J. Landin. The next 700 programming languages. Communications of the
ACM, 9:157-166, 1966.
[Mi1891 R. Milner. Communication and Concurrency. Prentice Hall, 1989.
[Mil92a] R.. Milner. Functions as processes. Mathematical Structures in Computer Science, 2(2):119-141, 1992.
[Mi192b] R. Milner. The polyadic r-calculus: A tutorial. In M. Broy, editor, Logic and
Algebra of Specification. Springer-Verlag, 1992.
[MPW92] R. Milner, J. Parrow, and D. WMker. A calculus of mobile processes. In]ormation and Computation, 100:1-77, 1992.
[Nie92] Oscar Nierstrasz. Towards an object calculus. In M. Tokoro, O. Nierstrasz, and
P.Wegner, editors, ECOOP'91, volume 612 of Lecture Notes in Computer Science,
pages 1-20. Springer-Verlag, 1992.
[San93] D. Sangiorgi. From pi-calculus to higher-order pi-calculus - and back. In [GJ93],
pages 151-166, 1993.
[Vaa90] F. W. Vaandrager. Process algebra semantics of POOL. In [Bae90], pages 173236. 1990.
[wal91] D. Walker. r-Calculus semantics of object-oriented programming languages. In
[IM91], pages 532-547, 1991.
[wal93a] D. Walker. Objects in the r-calculus. Information and Computation, 1993. (to
appear).
[Wa193b] D. Walker. Process calculus and parallel object-oriented programming languages.
In International Summer Institute Parallel Computer Architectures, Languages,
and Algorithms, Prague, 1993.
[Wo188] Mario I. Wolczko. Semantics o$ Object-Oriented Languages. PhD thesis, Department of Computer Science, University of Manchester, 1988.
169
A
T h e p o l y a d i c ~r-calculus
This appendix defines the version of the ~r-calculus used in this paper: the polyadic
(first-order) F-calculus from [Mil92b] is employed but the identification of abstractions and concretions as separate phrases of the language is not followed (although
the symmetry is pleasing, separating concretions appears to achieve little for the
purposes here; as for abstractions, the object-oriented position that everything is
located by name is taken here - this. would change if a higher-order calculus were
used). Unlike [Wa193a, MilU2a], (binary) sums are used here; summands are always
prefixed.
The syntax is very simple. Processes (typical elements P, Q), Normal processes
(typical elements M, N), and Prefixes (typical element ~r) are defined (z, y are used
as typical elements for names) as follows.
P ::= N IPIQI
N ::=
I 0 I M+
.::=
I
z(~) I YY
(17)
(is)
(19)
The omission of parenthesis on the output (negative) prefixes serves to remind the
reader that only input (positive) prefixes - and, of course, new names - serve to
bind names.
Prefix and new names bind more strongly than composition; sum binds weakest
of all. A number of abbreviations are useful. Trailing stop processes are omitted, so
7r.0 is written 7r. Multiple new names are combined, so (vz)(vy) is written (vzy). A
sequence of names such as al, a'2 is sometimes abbreviated to K. Recursive definitions
are written with an obvious meaning; they can actually be viewed as an abbreviation
of a 'baton' passing trick with replication.
Structural equivalences can be defined over this language. Alpha-convertible
terms are taken to be structurally equivalent; M / + / 0 (P/ [ /0) are symmetric
monoids; other laws include the following.
M+M-M
!P=_P[!P
(vz)O - 0
( v z ) ( v v ) P =- ( v y ) ( v z ) P
(ux)(P [ Q) - P I (vz)Q if z ~ fn(P)
(ux)v('i).P - u('i).(v~:)p w h e r e x # U, 9 ~t
(vx)~'~.P -- ~ . ( v x ) P where x r y, z ~
(vx)~r.P - 0 if ~ is z(~) or Y~
Where P{'~/'~} is the obvious syntactic substitution (with avoidance of accidental
capture).
170
The basic arguments used here rely of the notion of reduction whose rules can
be defined as follows. (Notice that there are no reductions under prefix, sum (or
replication).)
9 - { - - ~ . P + " ' ) 1("" + z ( ~ ) . Q + . . . ) --, P I Q(y/~}
_.~ p I
pjQP - - * P ' I Q
P~P'
( v x ) P ---* (vx)P'
I STRUC T IQ = t'
B
p t ~ Qi
P ~ P'
Q-~ Q'
Mapping
This appendix contains both an abstract syntax for wo~3A and the formal mapping
to the ~r-calculus. For ease of reading, concrete ~ro~A expressions are written as
arguments to [.]. The abstract syntax of a System shows it to be a collection of
named class definitions (Cdef).
System = Id m Cdef
Its semantics is given by an n-fold composition
[c1: cJ~ssC1,...,c,: dass C,]%f ie{1,....,n}
//
[Cdc~
Notice that the class name is needed as an argument to the mapping of the class
body. (Strictly, there should be an argument - say p - which is a one:one mapping
from {Cl,..., c.} to a set of w-calculus Names; this is avoided here by assuming that
ci are Names.) A single class definition contains
Cdef :: ivars : Id ~ Type
mm : Id--~-~ Mdef
Its semantics is given by
def
[vats vl: T 1 ; " . ; v,: T,; M]c = ! (vT~)(
II
Vi[ (vu)(-Su.[M]u))
i~{1,...,n}
Types are defined as follows (notice that NAT is handled as in Section 3.2).
Type = LOCALREF [ SHAREDREF ] BOOL
Method definitions contain
Mdef :: r : [Type]
pl : (Id x Type)*
b : Strnt
171
T h e semantics of the collection of such definitions is given by
[ml(x) method $ 1 , ' " , mn(x) method Snl
dee Bu
which is an n-fold sum
B. = (vt)(( iE{1S..... n} ~(~i~).~i.[&llu~)
Et().B.)
The mapping of a statement requires a termination label I, the unique name of the
current activation u (for self), and an appropriate termination indicator wi. The
different forms of statement are defined
Strut = Mref I Assign I Compound [ SKIP I / f ] While ] Return I Yield
The syntax and mapping of these follow.
Mref :: cn : Expr
mn : Id
al : Ezpr*
[e1!m(e2)llu~ dof=
(vl'l")([ex~Z'u I [e~]t"u I I'(u').u'(~).(~m)(l"(x).~m~.~0.7))
Assign :: lhs : Id
rhs : Expr
iv ~- ellu ~ d~J ( . * ' ) ( [ e l t ' u I s~(l').7)
Compound :: sl : Stmt*
[81;" "" ; Sn~lU~o dee ( V l l . . . ln_l)([$1]llUW I " "
I [~dlu~)
=l
[SKIP]luw der
If :: b : Expr
Ih : Strut
el : Strut
life then sl else s~_fi]luw def=
(vl' l~ l~)( BoolEval( l', l~, 12) I [e]l'u I ( Ix ().[s~]luw -1- 12().[s2]luw) )
Where BoolEval is as Equation 16 of Section 5.
While :: b : Ezpr
s : Stmt
172
s od]luw def
=W
w = (vt'tlt2e')(BootEval(t',
[while e do
Ii, 12)I [elll'u I (lzO.[dt"u~ + ~2().7)I r'(). w)
Return :: r : [Expr]
[return ]luw d_e_f~.7
[return e]luw def (vlt)([e]l,u
I z'(r).~r.?)
Yield :: r : Mref
[yield e~!m(e~)]luw ~r (~,l'l")([e~]l'u J [ez]l"u [ l'(u').u'(ff).l'(x).'a-~wz.7)
Expressions can be of the following forms.
Expr = New I Mref I NIL I SELF J Compare I And IId [ ]~
T h e m a p p i n g of expressions requires a label l for the n a m e of the result, and the
unique n a m e of the current activation u (for self).
New :: cn : ld
al : Expr*
[new c]lu de__fc(u).u(~).(VWn)('~nWn.Wn().TU)
[e~!m(e~)]lu%f
(~,l't")([edl'u
I [e=]l"u
I I'(u').u'(~).(,~,,)(r'(x).C~-,~,,,~,,=.~,~(r).Tr))
[n~]zu%f(.,n)(7.)
[self[ lu def lu
Compare :: el : Ezpr
e2 : Expr
lea = e2]lu dof=
(z, lxlz)([el]l~u I [e2]12u I t~(bl).(~,tf)(htf.(~()....
+ fO.'" ")))
And :: el : Ezpr
e2 : Expr
[el ^ e2] lu d~r=
(z,l~Iz)([e~]lxu [ [e~]Izu I I~(b~).(utf)(~tf.(t().Iz(bz).Tbz)+ fO.lby))
[v]lu d~r
= a,(x).Tz
[true]/d=ef lbt
[false] i de_rlb!