Causality for Debugging Mobile Agents �Pierpaolo Degano and Corrado PriamiDipartimento di Informatica, Universit�a di PisaCorso Italia, 40, I-56125 Pisa, Italy {fdegano,priamig@di.unipi.itLone Leth and Bent ThomsenEuropean Computer-Industry Research CentreArabellastr. 17, D-81925 Munich, Germany { flone,btg@ecrc.deOctober 7, 1996AbstractMobile agents, i.e. pieces of programs that can be sent around networks ofcomputers, are starting to appear on the Internet. Such programs may be seenas an enrichment of traditional distributed computing. Since mobile agentsmay carry communication links with them as they move across the network,they create very dynamic interconnection structures that can be extremelycomplex to analyse. In this paper we study an example of a system based onthe mobile agent principle written in the Facile programming language.We propose a Structural Operational Semantics (SOS) for Facile, giving aproved transition system that records encodings of the derivation trees oftransitions in their labels. This information allows us to easily recover non-interleaving semantics for Facile by looking only at the labels of transitions.We use the new Facile semantics to debug an agent based system. This ex-ample is a scaled down version of a system demonstrated at the European ITConference Exhibition in Brussels, 1995. We also adopt our causal semanticsto analyse the speci�cation of a prefetch pipeline processor.1 IntroductionWith the emergence of mobile agent based systems a new class of applications hasstarted to roam the information highway. Mobile agent based systems bring thepromise of new, more advanced and more exible services and systems. Mobileagents are self-contained pieces of software that can move between computers ona network. Agents can serve as local representatives for remote services, provideinteractive access to data they accompany, and carry out tasks for a mobile usertemporarily disconnected from the network. Agents also provide a means for theset of software available to a user to change dynamically according to the user'sneeds and interests [29].Mobile agents bring with them the fear of viruses, Troyan horses and othernastities. To avoid troubles of this kind, the main approach to agent based systemsis based on development of safe languages, i.e. languages that do not allow peek andpoke, unsafe pointer manipulations and unrestricted access to �le operations. This isoften achieved through interpreted languages. Java[17], Safe-TCL[14], Telescript[33]are examples of this approach.�Work partially supported by ESPRIT Basic Research Action 8130 - LOMAPS1

Even when the fear of viruses has been eliminated, mobile agent systems maybe a magnitude more complex to develop than traditional client/server applicationssince it is very easy to create agents that will counter act each other or inadvertently\steal" resources from other agents. Since an agent can move from place to place,it can be very hard to trace the execution of such systems and special care must betaken when constructing such systems.However, apart from being safe languages in the above sense, the mentionedlanguages are rather traditional, based on the object oriented paradigm and/ortraditional imperative scripting language techniques, thus these languages o�er verylittle support for the analysis of systems.Facile [15, 16, 30, 32] is a viable alternative to the above mentioned languages.Facile is a multi-paradigmprogramming language combining functional and concur-rent programming. The language is conceived for programming of reactive systemsand distributed systems, in particular the construction of systems based on theemerging mobile agent principle since processes and channels naturally are treatedas �rst class objects. Facile provides safe execution of mobile agents because theyonly have access to resources they have been given explicitly. Facile o�ers integrationof di�erent computational paradigms in a clean and well understood programmingmodel that allows formal reasoning about program behaviour and properties.Although Facile is still in an experimental phase, it is mature enough that ithas been used successfully to implement some larger distributed applications. Oneexample is the Calumet teleconferencing system [27, 28], which supports cooper-ative work through real-time presentations of visual and audio information acrosswide area networks, and Einrichten [1], an application that melds distribution, so-phisticated graphics, and live video to permit collaborative interior design workfor widely-separated participants. The latter application was demonstrated at the1995 G7 technology summit in Brussels. Another example, the Mobile Service Agentdemonstration [31], given at the EITC'95 Exhibition in Brussels, is the subject foranalysis in this paper.Facile may be viewed as an extension of �-calculus with primitives for concur-rency, communication and distribution. The language has a binding operator (�-abstraction) to de�ne (possibly higher-order) functions. Functions, processes andchannels may be either the result of the evaluation or the arguments of expressions.Facile handles concurrency through dynamic de�nition of processes, channelsand virtual processing units (called nodes). Processes exchange messages with sendand receive primitives along channels that are explicitly managed. Communicationis synchronous.The functional and the concurrent parts of Facile are strongly integrated: pro-cesses evaluate expressions to values while expressions may activate processes orreturn channels and node identi�ers.The semantics of Facile has been studied quite extensively [15, 16, 30, 20, 2],either focusing on de�ning the (abstract) execution of programs in terms of transi-tion systems, reduction systems or abstract machines, or being concerned with thedevelopment of program equivalences. So far the approach to semantics for Facilehas been based on the interleaving approach to modeling concurrency.In this paper we present a non-interleaving semantics for Facile, based on theparametric approach introduced in [12, 13]. We adopt a very concrete (SOS) tran-sition system whose transitions are labelled by encodings of their proofs. We theninstantiate it to causal semantics through relabelling functions, which maintain onlythe relevant information in the labels. This approach allows us to use the standardde�nitions and tools developed for the interleaving case.Furthermore, we use the non-interleaving semantics for Facile to debug the be-haviour of a mobile agent based system. The system we analyse is a scaled downversion of a problem with causal dependencies of higher order processes and mobile2

channels. It originally arose in the code for the Mobile Service Agent demonstra-tion. Using \traditional" debugging techniques it took two weeks to track down theproblem. We would like to point out that we will address the question of analysisof \real code". Even if we adopt here an analysis \post mortem", we can rely onthe operational semantics to simulate the system and foresee the wrong behaviour.This results in saving time and resources of a real network. Another case study thatwe report here concerns the speci�cation and analysis of hardware architectures us-ing an high-level language like Facile. We describe a prefetch pipeline processor byletting any of its logical component be a process on a virtual node. The advantageof our approach is that there will be no gap between model and implementationof a system. This is in sharp contrast to traditional analysis of systems. Here theanalysis takes place in a formal model of the system, but the system itself is im-plemented in a traditional programming language without formal foundation, thusthere is inevitably a gap between the formal model and the running code. Ourapproach is independent of the type of system being analysed; it applies to mobileagents, client/server or other concurrent programs.The rest of this paper is organised as follows: Section 2 introduces the syntaxof core Facile and in section 3 a Proved Transition System semantics is de�ned.Section 4 de�nes the notion of causality which may be derived from the ProvedTransition System semantics. Section 5 exempli�es the framework on some simplesystems. In section 6 we apply the mathematical framework to a case study derivedfrom a larger mobile agent based application implemented in Facile. Another casestudy is reported in section 7. It consists in the speci�cation of a prefetch pipelineprocessor and in the subsequent discovery of a bug. Finally, in section 8 we givesome concluding remarks.2 FacileIn this paper we consider only the core syntax of Facile, i.e. the set of constructswhich is su�cient to de�ne any Facile program. A translation from the full syntax tothe core syntax is given in [15]. The core syntax consists of three parts: expressions(functions) E, behaviour expressions (processes) BE and distributed behaviourexpressions (systems) DBE. Expressions are statically typed, and t ranges overtypes. We assume that all expressions are correctly typed. The type system isreported in [15]. Note that processes and systems have no type. See [30] for furtherdetails.2.1 SyntaxThe core syntax of Facile is given by the grammar in Tab. 1.V al, ranged over by v, denotes the set of syntactic values. Values are a subclassof expressions without free variables. Values can be passed as parameters to func-tions or be communicated between processes, possibly residing on di�erent nodesin a system.We assume a countable set of variables denoted by x; xi; : : :. Constants areranged over by c, and these include integers, booleans, channel-valued constants,node identi�ers and a distinguished value triv. Prede�ned operators such asif-then-else are denoted by c as well. We assume that all operations are incurried form to avoid the introduction of tuples and product types. Functions arede�ned and manipulated in �-calculus style with abstractions and applications. �is a variable binder with the usual notion of free and bound variables. The set offree variables of an expression is denoted by fn. fn is structurally extended tobehaviour expressions and distributed behaviour expressions. Substituting an ex-3

v ::= x j c j�x:e jcode(be)e ::= v j ee jspawn(be) j channel(t) j e!e j e?r spawn(e; be) jnewnode jnewnode(be)be ::= terminatejactivate(be) j bejjbe j be+ bedbe ::= n :: be jdbejjjdbeTable 1: Core syntax of Facile.pression for a variable with the usual avoidance of accidental binding is denoted bye[e0=x]. For a formal de�nition of these concepts see [15]. Normally we only needto substitute values for variables. The code construct transforms a process into avalue that can be used in the functional style. More precisely, code(be) is a processclosure whose behaviour is described by be. A new channel on which we can trans-mit values of type t is generated by channel(t). The send operation e1!e2 sendsthe value resulting from the evaluation of e2 along the channel resulting from theevaluation of e1. The operation returns the value triv when the receiver gets thevalue. The receive operation e? returns the value read on the channel resulting fromthe evaluation of e. The evaluation of spawn(be) and r spawn(e; be) both return thevalue triv. The spawning operations have the e�ect of concurrently executing theprocess speci�ed by be on the current virtual node, respectively on the virtual nodeidenti�ed by the evaluation of e. The expressions newnode and newnode(be) createthe identi�er of a new virtual node. The former expression leaves the new nodeempty, while the latter allocates the process be on the new node.Unlike evaluation of expressions, the execution of behaviour expressions does notproduce values. The simplest process is terminate which does not do anything.The process activate(e) activates the evaluation of the expression e. The operatorjj describes the parallel composition of processes allocated on the same virtual node.The operator + denotes non-deterministic choice.The last syntactic category DBE describes distributed systems consisting of acollection of nodes. The construct n :: be means that process be is allocated on noden. The parallel composition operator jjj concurrently composes processes allocatedon di�erent nodes.jj has precedence over jjj since DBE is de�ned in terms of BE. Therefore,be1jjbe2 jjjbe3 means (be1jjbe2) jjjbe3.2.2 Operational semanticsWe de�ne the operational semantics of Facile in SOS style [24] through a labelledtransition system. We start with the de�nition of the alphabet for the labels.Let S be the set of all channels, and St be its subset consisting of channels onwhich we can transmit values of type t. We say that a value v is transmissible ona channel k if v has type t (for short ; ` v : t) and k 2 St.De�nition 2.1 (Labels) Let N be a countable in�nite set of nodes. Then,` 2 L = fk(v); k(v) j 9t : (k 2 St; v 2 V al; ; ` v : t)g [ f�g [ N [f�(be) : be 2 BEg [ f(be! n) : be 2 BE; n 2 Ng [ fn(be) : n 2 N ; be 2 BEg4

1:a : K;N; e1 ��!e K 0;N 0; e01K;N; e1e2 ��!e K 0;N 0; e01e2 1:b : K;N; e2 ��!e K 0; N 0; e02K;N; v e2 ��!e K 0; N 0; v e021:c : K;N; (�x:e)v ��!eK;N;e[v=x]2:a : K;N; e1 ��!e K 0;N 0; e01K;N;e1 ! e2 ��!e K 0;N 0; e01 ! e2 2:b : K;N;e2 ��!e K 0;N 0; e02K;N; k ! e2 ��!e K 0;N 0; k ! e022:c : K;N; k ! v k(v)�!e K;N;triv; k 2 K 3:a : K;N;e ��!e K 0;N 0; e0K;N; e ? ��!e K 0;N 0; e0 ?3:b : K;N; k ? k(v)�!e K;N; v; k 2 K;k 2 St; ; ` v : t4: : K;N;channel(t) ��!e K [ fkg; N;k; k 62 K;k 2 St5: : K;N;spawn(be) �(be)�!eK;N;triv6:a : K;N;e ��!eK 0;N 0; e0K;N;r spawn(e; be) ��!eK 0;N 0;r spawn(e0; be)6:b : K;N;r spawn(n; be) (be!n)�!e K;N;triv7: : K;N;newnode n�!eK;N [ fng; n n 62 N8: : K;N;newnode(be) n(be)�!e K;N [ fng; n n 62 NTable 2: Function expressions.is an action. We call Comm the �rst set in the de�nition of labels L.The intuitive meaning of labels is as follows. Receiving the value v on channel k isdenoted by k(v), and sending the value v on channel is denoted by k(v). We call k(v)and k(v) complementary labels. The label � denotes invisible actions, the labels�(be) and (be ! n) are introduced by spawn(be) and r spawn(n; be), respectively,and the labels n and n(be) are introduced by newnode and newnode(be), respectively.We now de�ne con�gurations of the labelled transition system of Facile. Let 2Sf(ranged over by K) and 2Nf (ranged over by N ) be the set of �nite subsets of S andN , respectively. These sets are used to ensure uniqueness of channels and nodes.Creation of channels and nodes inserts the new name into the corresponding set incon�gurations if it does not already exist (see rules 4 and 8 in Tab. 2). The sets ofcon�gurations are Econ � 2Sf � 2Nf � E for expressionsBcon � 2Sf � 2Nf � BE for processesDBcon � 2Sf � 2Nf �DBE for systems.Transition relations between con�gurations are de�ned as follows. The relation�!e� Econ � L �Econ5

9:a : K;N;e ��!e K 0;N 0; e0K;N;activatee ��!beK 0;N 0;activatee0 ; � 6= �(be)9:b : K;N;e �(be)�!e K 0; N 0; e0K;N;activatee ��!beK 0; N 0;activatee0jjbe9:c : K;N;activatecode(be) ��!beK;N; be10:a : K;N;be1 ��!be K 0;N 0; be01K;N;be1jjbe2 ��!be K 0;N 0; be01jjbe210:b : K;N;be2 ��!be K 0;N 0; be02K;N;be1jjbe2 ��!be K 0;N 0; be1jjbe0211: : K;N; be1 ��!beK 0;N 0; be01 K;N;be2 ��!be K 0;N 0; be02K;N;be1jjbe2 ��!beK 0;N 0; be01jjbe0212:a : K;N; be1 ��!be K 0;N 0; be01K;N;be1 + be2 ��!beK 0;N 0; be0112:b : K;N; be2 ��!beK 0;N 0; be02K;N;be1 + be2 ��!beK 0;N 0; be02Table 3: Behaviour expressions.evaluates expressions. For instance, we have K;N; e �̀!e K0; N 0; e0. The transitionrelation for processes is�!be� Bcon � Ln f�(be) : be 2 BEg �Bcon. A derivation step is written K;N; be �̀!be K0; N 0; be0. Finally, transitions forsystems are expressed by�!dbe� DBcon � (Comm �N ) [ f�g �DBconA derivation step is written K;N; dbe �̀!n dbe K0; N 0; dbe0 where ` 2 Comm andK;N; dbe ��!dbe K0; N 0; dbe0.We can now de�ne the labelled transition system for Facile.De�nition 2.2 (Labelled Transition System) The labelled transition system forFacile is LTS = hDBcon; L;�!dbei where DBcon is the set of con�gurations ofsystems, L is the set of labels and �!dbe is the transition relation de�ned by axiomsand rules in Tables 2, 3, 4.Detailed comments to the rules of Tables 2, 3, 4 and 5 are given in [30]. Herewe introduce some notation that will be used later on. The core of Facile hasno operator for sequentialisation of expressions or processes. The term e1:e2 isimplemented in the core language as:e1:e2 � (�x:e2)e1 if x 62 fn(e2)6

13:a : K;N; be ��!beK 0;N 0; be0K;N;n :: be ��!dben K 0;N 0; n :: be0 ; � 6= n;n(be); (be! n); �13:b : K;N; be n�!be K 0;N 0; be0K;N;n0 :: be ��!dbeK 0;N 0; n0 :: be0jjjn :: terminate13:c : K;N; be n(be00)�!be K 0;N 0; be0K;N;n0 :: be ��!dbe K 0;N 0; n0 :: be0jjjn :: be0013:d : K;N; be (be00!n)�!be K 0;N 0; be0K;N;n0 :: bejjjn :: be000 ��!beK 0;N 0; n0 :: be0jjjn :: (be000jjbe00)13:e : K;N; be ��!be K 0;N 0; be0K;N;n :: be ��!dbe K 0;N 0; n :: be014:a : K;N; dbe1 ��!dben K 0;N 0; dbe01K;N;dbe1jjjdbe2 ��!dben K 0;N 0; dbe01jjjdbe214:b : K;N; dbe2 ��!dben K 0; N 0; dbe02K;N;dbe1jjjdbe2 ��!dben K 0; N 0; dbe1jjjdbe02Table 4: Distributed behaviour expressions.7

14:c : K;N; dbe1 ��!dbeK 0;N 0; dbe01K;N;dbe1jjjdbe2 ��!dbeK 0;N 0; dbe01jjjdbe214:d : K;N;dbe2 ��!dbeK 0;N 0; dbe02K;N; dbe1jjjdbe2 ��!dbeK 0;N 0; dbe1jjjdbe0215: : K;N; dbe1 ��!dben K 0;N 0; dbe01 K;N; dbe2 ��!dben0 K 0;N 0; dbe02K;N;dbe1jjjdbe2 ��!dbeK 0;N 0; dbe01jjjdbe02Table 5: Distributed behaviour expressions (cont.).where fn(e) denotes the free variables of e. The term e:be is translated ase:be � activate((�x:code(be))e) if x 62 fn(be)In the following we will use sequentialisation to simplify the representation ofFacile systems. When the direction of communication is immaterial we may simplywrite a:be and when an action is the last action of a processes, i.e. a:terminate wemay drop the terminate behaviour expression and simply write a.We adopt the following conventions on the representation of computations (i.e.sequences of transitions). We only visualise nodes and branches of computationsthat are interesting for the study at hand. Nodes which are not essential are rep-resented as `�'. To ease the understanding of labels (always listed on the left-handside of arcs) we write the operation corresponding to the actual transition on theright-hand side of some arcs labelled � . Thus, we will have arcs with the format� #; 0operation0. i0; i00; i000 denote the actions of process bei when their exact natureis irrelevant. Furthermore, we write newnode for both newnode and newnode(be) ifno confusion arises.Creation of nodes and processes may alter the structure of systems. The creationof a new process depends on whether it is local or remote to the node that executesthe operation. If it is local, i.e. created by spawn(be), the new process be is put inparallel with the processes that already run on the current node:: : : (n1 :: spawn(be):�jjbe1jjbe2) jjj (n2 :: : : :� #; spawn(be): : : (n1 :: (�jjbe)jjbe1jjbe2) jjj (n2 :: : : :When the new process be must be activated on a node di�erent from the currentnode, i.e. r spawn(n; be) is executed, the process be is placed as the last componentof the parallel composition describing node n:: : : (n1 :: r spawn(n2; be):�jjbe1) jjj (n2 :: be2jjbe3) jjj : : :� #; r spawn(n2;be): : : (n1 :: �jjbe1) jjj (n2 :: be2jjbe3jjbe) jjj : : :The creation of a new node modi�es the system by inserting the new nodeimmediately to the right of the node that executes the operation:: : : (n1 :: be1jjbe2) jjj (n2 :: newnode(be):�jjbe3) jjj (n3 :: be4 : : :� #; newnode(be): : : (n1 :: be1jjbe2) jjj ((n2 :: �jjbe3) jjjn4 :: be) jjj (n3 :: be4 : : :8

3 Proved Transition SystemIn this section we de�ne the proved operational semantics of Facile following [5].First we modify the core syntax of Facile to eliminate the set N of nodes and theset K of channels from con�gurations. Nodes will from now on be denoted bynatural numbers that identify the position of nodes within Facile systems. Nodesare ordered from left to right, starting with 1. We add a syntactic category program.A program is a distributed behaviour expression with a begin and an end guard n,with n 2 INnf0g. The two guards denote the number of nodes in the system. Todistinguish these guards from other integers we write them in boldface. The newsyntax of Facile is obtained from the syntax given in Def. 1 by modifying distributedbehaviour expressions as dbe ::= be jn j dbejjjdbeand de�ning programs as p ::= njjjdbejjjn:Hereafter, the set of programs will be denoted by P . Static checks ensure that dbein njjjdbejjjn does not contain any distributed behaviour expression equal to n. Tode�ne the semantics of r spawn(e; be) we add an end guard, denoted x, to processes.Thus, behavioural expressions are extended with the following two itemsbe ::= : : : j bejjx j xAgain, static checks ensure that be in be jj x does not contain x. Finally, to simplifythe de�nition of causality and locality semantics of Facile, we assume that both jjand jjj are right associative.3.1 Labels of transitionsWe start with the de�nition of actions. In the following de�nition the set Comm isas in Def. 2.1.De�nition 3.1 (actions) The set Act of actions is:Comm [ f�g [ f(�; k) : k 2 Sg [ fnew(be) : be 2 BEg [f(be! n; i) : be 2 BE; n 2 IN; i 2 Zg:Elements of Act are denoted as �; �i; �0; : : :.The label (�; k) is caused by channel(t) and contains the name of the new channel.The label new(be) denotes the creation of a new node on which be is activated.Finally, the label (be! n; i) represents the creation of a new process to be activatedon node n. The value 0 is assigned to n for spawn(be) since be is activated on thesame node as the spawn operation itself. The integer i denotes the number of jjjoperators between the node n and the node performing the r spawn, i.e. i is therelative address of the two nodes.Following the developments in [12, 13], we extend actions with the parallel struc-ture of the process which executes them.De�nition 3.2 (proof terms) Let � 2 Act, � 2 fjjj0; jjj1g�, and # 2 fjj0; jj1g�.The set � of proof terms is:f�#�g [ f�#h�0#0�; �1#1��i : � 2 Commg [ f�0#0��1#1�gElements of � are denoted as �; �i; �0; : : :.9

The proof term �#� is the label of a generic action � executed by a processwhose position is encoded by �#. The synchronisation of two processes is labelled�#h�0#0�; �1#1��i. The label �0#0��1#1� encodes either the creation of a new nodeor the allocation of a process through an r spawn; its use will be clear later on.The following example shows the intuition behind proof terms. Consider thecomputation in Fig. 1: The label jjj1jjj0jj0� of the �rst transition says that theprocess at position jjj1jjj0jj0 performs an internal action � . Since jjj and jj areright-associative, the transition is caused by the spawn(be1) pre�x.Unlike in the standard semantics of Facile (see Sect. 2), a new node is placedimmediately before the end guard (second transition). The proof part before �is the position of the process that performs the newnode without considering thenode created. The proof part after � is the position of the node just created. Notethat the proof term of a newnode will end with jjj0jj0 because of the end guards ofsystems and processes that impose the presence of a jjj at the right of each nodeand of a jj at the right of each process.The third transition is due to r spawn. The �rst part of its label is the addressof the process that executes the operation. The proof part after � is the addressof the process spawned which is placed immediately before the end guard of thedestination node.The last transition is a communication. Its label shows that v is transmittedalong channel k. The sender and the receiver are located at jjj1jjj0jj1jj0 and jjj21jjj0jj0,respectively. Assume that the residual of the receiver is in uenced by the valuev. Then becomes 0.3 jjjspawn(be1):�jjk ! v:�jj�jjjk ?: jjnewnode(be4):�jjxjjjr spawn(2; be5):�jjxjjj33 jjj (�jjbe1)jjk ! v:�jjxjjjk ?: jjnewnode(be4):�jjxjjjr spawn(2; be5):�jjxjjj34 jjj (�jjbe1)jjk ! v:�jjxjjjk ?: jj�jjxjjjr spawn(2; be5):�jjxjjjbe4jjxjjj44 jjj (�jjbe1)jjk ! v:�jjxjjjk ?: jj�jjbe5jjxjjj�jjxjjjbe4jjxjjj44 jjj (�jjbe1)jj�jjxjjj 0jj�jjbe5jjxjjj�jjxjjj be4jjxjjj4jjj1 jjj0 jj0�jjj21 jjj0 jj1 jj0�jjj41 jjj0 jj0�jjj31 jjj0 jj0�jjj21 jjj0 jj21 jj0�jjj1 hjjj0 jj1 jj0k(v);jjj1 jjj0 jj0k(v)iFigure 1: A computation of a Facile program.3.2 Auxiliary functionsWe now introduce some auxiliary functions that are needed to de�ne the provedsemantics of Facile. The �rst function ` is used to recover the action starting froma proof term. It can also be used to obtain the interleaving semantics of Facile.De�nition 3.3 (`) Let � 2 fjj0; jj1; jjj0; jjj1g. Then the function ` : � ! Act isde�ned as:`(�) = � ; `(h�0#0�; �1#1��i) = � ; `(�0�0��1�1) = � ; `(��) = `(�)We extend the involution to ` as follows.`(�) = k(v) if `(�) = k(v)10

The second auxiliary function C returns the channel valued constants in a Facilesystem. When creating a new channel name, the function is used to check whetherthis name is already in use. The function C works recursively through expressions,behaviour expressions and distributed behaviour expressions.De�nition 3.4 (C) The function C : E [BE [DBE ! S is de�ned by structuralinduction as follows:C(x) = ; C(c) = � fcg if c 2 S; otherwiseC(�x:e) = C(e) C(e1e2) = C(e1) [ C(e2)C(channel(t)) = ; C(e1!e2) = C(e1) [ C(e2)C(e?) = C(e) C(code(be)) = C(be)C(x) = ; C(spawn(be)) = C(be)C(r spawn(e; be)) = C(e) [ C(be) C(newnode) = ;C(newnode(be)) = C(be) C(be1 jj be2) = C(be1) [ C(be2)C(be1 + be2) = C(be1) [ C(be2) C(activate(e)) = C(e)C(terminate) = ; C(dbe1 jjj dbe2) = C(dbe1) [ C(dbe2)C(n) = ;Recall that the set S in the above de�nition is the set of all channels (see Sub-sect. 2.2).The function F below computes the position of the node on which a new processis activated through an r spawn(be). Its parameters are the address � of the processwhich performs the r spawn and the number i of jjj between the node identi�ed by� and the node on which be will run. The number i is positive if the node, on whichthe new process is activated, is to the right of the node that performs the r spawn.i is negative if the node is to the left. Note that the index i will be obtained fromthe labels of transitions coming from r spawn operations.De�nition 3.5 (F) The function F :fjjj0; jjj1g+ � Z ! fjjj0; jjj1g+ is de�ned as:1. F(�; 0) = �;2. F(�; i) = F(jjj1�; i� 1) if i > 0;3. F(jjj1�; i) = F(�; i+ 1) if i < 0Note that we do not use fjjj0; jjj1g� in the domain and codomain of F because ofthe end guard of programs. In fact, the proof term which encodes the position ofnodes within a program is always of the formfjjj1g+jjj0because jjj is right associative and programs have a begin and an end guard. Intu-itively, the position of the node, on which the new process is activated, is obtainedfrom the position of the node that executes the r spawn by adding (if i > 0) orsubtracting (if i < 0) the absolute value of i occurrences of jjj1.The function B builds the label of a behaviour expression be allocated on anode by an r spawn. It also builds the structure of the destination node. The�rst parameter of B is the process that must be put in parallel with the processto be spawned (second parameter). The last parameter is the address, computedinductively, of the process to be spawned.De�nition 3.6 (B)The function B : BE � BE � fjj0; jj1g+ ! BE � fjj0; jj1g+ is de�ned as:11

1. B(be1jjx; be; #) = be1jjbejjx; #jj0; 12. B(be1jjbe2; be; #) = be1jjB(be2; be; #jj1) if be2 6= xThe function D computes the structure of a node created through a newnode(be)and the address of the process to be activated on it. D computes similarly to B.De�nition 3.7 (D)The function D : DBE �DBE � fjjj0; jjj1g+ ! DBE � fjjj0; jjj1g+ is de�ned as:1. D(dbejjjn; be; �) = dbejjjbejj�jjjn+ 1; �jjj0jj0;2. D(dbe1jjjdbe2; be; �) = dbe1jjjD(dbe2; be; �jjj1) if dbe2 6= nNote that both B and D have strings of jji and jjji of length at least one in theirdomains and codomains. This is because they are applied with # = jj1 for B and� = jjj1 for D (see rules 16:e, 16:m and 17:b in Tables 9, 10 and 11).3.3 Transition relationWe now de�ne the proved transition system of Facile.De�nition 3.8 (proved transition system) The proved transition system of Facileis the triple PTS = hT;�;�!pi where T is the set of closed Facile programs, � isthe set of proof terms, and �!p is the transition relation de�ned in Tables 6 ,: : :,11.We introduce a new transition relation for programs�!p� Prog �� � Prog:Before discussing the rules that de�ne the operational semantics, we state aproposition that relates the original and the proved semantics of Facile. The proofis by induction on the rules that de�ne the transition relations.Proposition 3.9Let ��! and ��!p be the transition relations in Defs. 2.2 and 3.8, respectively. Then,K;N; dbe ��! K 0; N 0; dbe0 , 9� : dbe ��!p dbe0 ^ `(�) = �3.3.1 ExpressionsHere we examine the rules of expressions (Tab. 6). As in Def. 2.2, the creation of anew channel returns the name of that channel. We must ensure that the new nameis not already in use elsewhere in the program to avoid name confusion. Since thechannel generated by channel(t) is recorded in the labels of transitions (see rule 4:),we perform the name clash check at each derivation step by checking the condition`(�) = (�; k) ) k 62 C(�). The same condition is applied in the rules for parallelcomposition of processes and systems. Note that in rule 3:a there is not the abovecondition because channel names have already been checked inductively during thederivation of the premise. Instead, rule 6:a has the condition because, even if emust evaluate to a node identi�er, it is possible to create channels and to exportthem in communications beforehand. Since we check channel names when they are1To avoid the introduction of projection functions on pairs, we avoid the pair constructors hand i. This allows us to build proof terms correctly without composing projections.12

1:a : e1 ��!e e01e1e2 ��!e e01e2 ; �̀ (�) = (�; k) )k 62 C(e2) 1:b : e2 ��!e e02ve2 ��!e ve02 ; �̀ (�) = (�; k) )k 62 C(v)2:a : e1 ��!e e01e1 ! e2 ��!e e01!e2 ; �̀ (�) = (�; k) )k 62 C(e2) 1:c : (�x:e)v ��!e e[v=x]2:b : e2 ��!e e02k!e2 ��!e k!e02 ; �̀ (�) = (�; h) )h 6= k 2:c : k!v k(v)�!e triv; �k 2 St; ` v : t3:a : e ��!e e0e? ��!e e0? 3:b : k? k(v)�!e v; �k 2 St; ` v : t4: : channel(t) (�;k)�!e k; k 2 St 5: : spawn(be) (be! 0;0)�!e triv6:a : e ��!e e0r spawn(e; be) ��!e r spawn(e0; be) ; �̀ (�) = (�; k) )k 62 C(be)6:b : r spawn(n; be) (be! n;0)�!e triv; n > 07: : newnode new(terminate)�!e $ 8: : newnode(be) new(be)�!e $Table 6: Proved function expressions of Facile.created, clash of names would arise without the condition. The distributed checkon channel names allows us to drop the set K of channels from con�gurations.The (be! n; 0) label in rules 5 and 6.b represents the creation of a new processbe by either spawn(be) if n = 0 or r spawn(n; be) otherwise. The second componentof the pair is 0 because we do not know the relative address of n with respect tothe current node. The label is updated with this information in either rule 16:b or16:c or 16:m. The integer allows us to apply the function F correctly in rule 17:c.The new(be) label in rules 7 and 8 records the process that must be activatedon the new node. This process is terminate for the creation of an empty nodeand be otherwise. We distinguish nodes according to their position within theprogram. Each time we generate a new node, its position is determined by theguards of systems. Since we do not know the value of guards at the expression levelwe introduce a placeholder $ that is instantiated at the program level in rule 17.b(Tab. 11). Identifying nodes with their position allows us to eliminate the set N ofnodes from con�gurations.3.3.2 Behaviour expressionsConsider the rules of behaviour expressions. The tag jj0 in rule 10.a means that theleft component of a parallel composition moves, the tag jj1 in rule 10.b means thatthe right component moves. When two processes be1 and be2, allocated on the samenode, communicate (rule 11), the label on the transition is the pair of the actionsperformed by the two partners �1 and �2, decorated with their positions jj0 and jj1,respectively.The non-deterministic choice + does not change the labels (rules 12.a and 12.b)because the non-interleaving relations, in which we are interested, are interpreta-tions of the parallel structure of processes only. There is no need for checkingchannel names in rules 12.a-b, because the choice operator discards either sum-mand be2 or be1. Assume that be1 generates a channel k which already exists in13

9:a : e ��!e e0activatee ��!be activatee0 ; `(�) 6= (be! 0; 0)9:b : e #(be!0;0)�!e e0activatee #��!be activatee0jj be9:c : activatecode(be) ��!be be 10:a : be1 ��!be be01be1 jj be2 jj0��!be be01 jj be2 ; �̀ (�) = (�; k) )k 62 C(be2)10:b : be2 ��!be be02be1 jj be2 jj1��!be be1 jj be02 ; �`(�) = (�; k) )k 62 C(be1)11: : be1 �1�!be be01 be2 �2�!be be02be1 jj be2 hjj0�1;jj1�2i�!be be01 jj be02 ; `(�1) = `(�2)12:a : be1 ��!be be01be1 + be2 ��!be be01 12:b : be2 ��!be be02be1 + be2 ��!be be02Table 7: Proved behaviour expressions of Facile.be2. Since the rule discards be2, there is no name clash and the name can be re-used.The symmetric case is similar.13:a : be ��!be be0be ��!dbe be0 ; `(�) 6= (be00 ! n; 0)13:b : be #(be00!n;0)�!be be0#(be00!n;0)bejjjdbe �! be0jjjdbe1 014:a : dbe1 ��!dbe dbe01dbe1 jjjdbe2 jjj0��!dbe dbe01jjjdbe2 ; `(�) = (�; k) ) k 62 C(dbe2)14:b : dbe2 ��!dbe dbe02dbe1 jjjdbe2 jjj1��!dbe dbe1jjjdbe02 ; `(�) = (�; k) ) k 62 C(dbe1)15: : dbe1 �1�!dbe dbe1 dbe2 �2�!dbe dbe02dbe1 jjjdbe2 hjjj0�1;jjj1�2i�!dbe dbe01jjjdbe02 ; `(�1) = `(�2)Table 8: Proved distributed behaviour expressions of Facile.3.3.3 Distributed behaviour expressionsWe now examine distributed behaviour expressions. The only di�erence betweendistributed behaviour expressions and behaviour expressions is in the rules for par-allel composition and communication where we use tags jjji instead of jji.If the operation is an r spawn(e; be) we must �nd the node n on which theprocess is to be activated. For this purpose we de�ne a quite technical auxiliary14

16:a : �dbe1jjjdbe2jjjdbe3 �! dbe01jjjdbe2jjjdbe3i 0�(dbe1jjjdbe2)jjjdbe3 �! (dbe01jjjdbe2)jjjdbe3i+1 0 ; dbe3 6= n16:b : #(be00!n;0)dbe1jjjbejjjn �! dbe01jjjbejjjni 0#�#0(be00!n;i)dbe1jjjbejjjn �! dbe01jjjbe0jjjn0 i ; B(be; be00; jj1) = be0; #016:c : #(be00!n;0)dbe1jjjbejjjn0 �! dbe01jjjbejjjn0i 0#(be00!n;0)dbe1jjjbejjjn0 �! dbe01jjjbejjjn0i n0�1 ; n 6= n016:d : #(be00!n;0)(dbe1jjjbe)jjjdbe3 �! (dbe01jjjbe)jjjdbe3i j#(be00!n;0)dbe1jjjbejjjdbe3 �! dbe01jjjbejjjdbe3i�1 j�1 ; j > n; i > 116:e : #(be00!n;0)(dbe1jjjbe)jjjdbe3 �! (dbe01jjjbe)jjjdbe3i n#�#0(be00!n;i�1)dbe1jjjbejjjdbe3 �! dbe01jjjbe0jjjdbe30 i�1 ; �B(be; be00; jj1) =be0; #016:f : �(dbe1jjjdbe2)jjjdbe3 �! (dbe01jjjdbe2)jjjdbe030 j�dbe1jjjdbe2jjjdbe3 �! dbe01jjjdbe2jjjdbe030 j�1 ; j 6= 116:g : �dbe �! dbe00 1dbe jjj0��!dbe dbe0Table 9: Proved distributed behaviour expressions of Facile (cont.).relation. (Its de�nition can be skipped by the non-interested reader, reading canthen be resumed with the rules for programs.) In rule 13:b we consider all nodes onthe right of the current node. The indices 1 and 0 indicate that we move a positionto the right but we do not know the name of the new node yet (there is at least theend guard). The auxiliary relation ��!i jis de�ned in Tables 9 and 10. The index i denotes the number of jjj operatorsbetween the node that performs the r spawn and the node under consideration.In other words, it denotes the right shift, with respect to the address of r spawn,if i is positive or the left shift if i is negative. Since parallel operators are right-associative, we move to the right until the end guard by making jjj left-associativethrough parentheses (rule 16:a).Assume that we want to allocate a process at the right of the spawning node.When the end guard is reached (at this point we know the number of nodes in thesystem), we consider the nodes to the left of the end guard by recovering the rightassociativity of jjj. We initialise index j to the number of nodes in the system (rule16:c) and we move to the left until the destination node is reached, by decrementingindices i and j (rule 16:d). When the destination node is identi�ed, we allocate thespawned process on this node, and we add its local address to the label of thetransition (rule 16:e and function B). Note that jj1 in the call to B is needed tokeep track of the jj operator inserted in the node to allocate the new process be00(see also Def. 3.6). What remains is to restore the associativity up to the node15

that performs the r spawn. We replace the value of j with the number of stepsneeded to reach the spawning node (i� 1). The index i is no longer needed and weset it to 0 (rule 16:f). The same happens in rule 16:b, handling the case in whichthe destination node is the node immediately to the left of the end guard. Whilemoving to the left and recovering right associativity, we decrement the index j untilit becomes 1. Index j is 1 when we are on the node performing r spawn. Now weadd a jjj0 in the label of the transition to build the proof term correctly, and weresume the actual transition relation (rule 16:g).If the destination node is at the left of the node performing r spawn, the index ibecomes 1 before j. This means that we are back on the node performing r spawn,and the destination node has not been found. We add a jjj0 to the label of thetransition, and we set the index i to 0 (rule 16:h). Rule 16:i handles the case inwhich the node performing r spawn is immediately at the left of the end guard.We continue moving left by decrementing the indices i and j and by adding jjj1s inthe labels to update proof terms correctly (rule 16:l). This is the case in which theshift with respect to the node of r spawn yields a negative index i. When index jbecomes n + 1, we allocate the process, we build its local address and we resumethe actual transition relation (rule 16:m and function B). The last parameter of Bis needed for the same reason as in rule 16:e (see above). Note that we store theindex i � 1 in the label of the transition. This will be used by the function F inrule 17:c.16h : #(be00!n;0)dbe �! dbe01 jjjj0#(be00!n;0)dbe �! dbe00 j ; j > 0 16:i : #(be00!n;0)bejjjn0 �! be0jjjn01 0jjj0#(be00!n;0)bejjjn0 �! be0jjjn00 n016:l : �#(be00!n;0)dbe �! dbe0i jjjj1�#(be00!n;0)bejjjdbe �! bejjjdbe0i�1 j�1 ; i � 0; j > n+ 116:m : �#(be00!n;0)dbe �! dbe0i n+1bejjjdbe jjj1�#�#0(be00!n;i�1)�!dbe be0jjjdbe0 ; �B(be; be00; jj1) = be0; #0i � 0Table 10: Proved distributed behaviour expressions of Facile (cont.).3.3.4 ProgramsNow we consider the rules of programs. Rule 17:b replaces the placeholder $ (gen-erated by either rule 7 or 8) with the value of the guards plus one. The function Dallocates the new node and recovers its address. The parameter jjj1 keeps track ofthe jjj operator added to the program to allocate the new node. Note that the tagjj0 in the side condition of rule 17:b keeps track of the end guard of nodes insertedby newnode. At the program level, if the operation is r spawn, we only need tocomplete the label with the function F (rule 17:c). We internalise the creation ofchannels by transforming its label into � (rule 17:d).Even if the labels of newnode and r spawn have the same structure at the pro-gram level, we can always distinguish them. In fact, the r spawn label has at leastone jj1 between the jjj0 that ends the sequence of jjji after �, and the jj0 that ends thesequence of jji. The labels of newnode do not have this. The following propositionexpresses this. 16

17:a : dbe ��!dbe dbe0n0jjjdbe jjj1��!p n0jjjdbe0 ; `(�) 6= new(be); (be! n; i); (�; k)17:b : dbe �#new(be)�!dbe dbe0n0jjjdbe jjj1�#��0jj0��!p n0 + 1jjjdbe00fn0 + 1=$g ; �D(dbe0; be; jjj1) =dbe00; �0jj017:c : dbe �#�#0(be!n;i)�!dbe dbe0n0jjjdbe jjj1�#�F(�;i)#0��!p n0jjjdbe0 17:d : dbe �#(�;k)�!dbe dbe0n0jjjdbe jjj1�#��! p n0jjjdbe0Table 11: Proved programs of Facile.Proposition 3.10 Let � and �0 be the labels of a newnode and an r spawn, respec-tively. Then, � = fjjj1g+jjj0fjj0; jj1g�jj0�fjjj1g+jjj0jj0�and �0 = fjjj1g+jjj0fjj0; jj1g�jj0�fjjj1g+jjj0fjj0; jj1g�jj1jj0�Proof. The proof part before � is the same for both � and �0 because � encodes theposition of the process which performs the operation. The tags jjj0 and jj0 are alwayspresent because of the end guards of programs and processes.Now consider the proof term which follows � in �. The tags jjj0 and jj0 are always presentfor the same reasons as above. Since the nodes created are placed immediately before theend guard of programs, their addresses end with jjj0. The process allocated on the newnode is at the left of the end guard x and there is no other process on the node. Therefore,the process address is jj0.Now consider the proof part after � in �0. The same arguments as in the case above stillhold for jjj0. Since r spawn places the process on an existing node, that therefore containsat least one process apart from the end guard x, we have fjj0; jj1g�jj1 before the last jj0.4 CausalityThe study of the behaviour of a distributed system may bene�t from knowledgeon the causal relation between its events. For example, when debugging a system,it might be very expensive to examine all the observable events which precede adetected bug. It is much simpler only to look at the events which have in uencedthe bug. These are identi�ed by a causality relation which traces the e�ects thatan action has on those actions that it causes. [34, 11, 10, 25, 6, 18].Recently a few papers [4, 13, 23, 8, 19] have begun to study this relation inpresence of mobility relying on �-calculus [21, 22].Facile can express the distribution of processes on nodes. As a consequence, thereare several kinds of causality that can be considered. In this paper we explore infra-and intra-node causality, respectively. Infra-node causality considers transitions atthe node level by assuming that the internal structure of each node is sequential.This assumption corresponds to having uniprocessor nodes. Intra-node causality isan extension of node causality introducing the parallel structure of processes. Thisis the case of multiprocessor nodes. Hereafter, let 2 A [ f��#�g.17

4.1 Infra-node causalityWe de�ne infra-node causality by interpreting the parallel structure of systems.Therefore, we only consider the pre�x of proof terms made up of jjji. For thesake of readability, we distinguish between communications and other operations.Following this scheme we de�ne two dependency relations and then we composethem to obtain infra-node causality.De�nition 4.1 (v1) Let P0 �0�!p P1 �1�!p : : : �n�!p Pn+1 be a proved computationand let �n = �0#0 0. Then, �n has a direct dependency on �h (�h v11 �n) i� either�h = �0# or �h = �#��0#00� .The dependencies of �n are obtained by the re exive and transitive closure of v11,i.e., v1 = (v11)�.Note that we have reduced the pre�x relation between proof terms to equalitybecause Facile does not allow nodes to have sub-nodes.De�nition 4.2 (v2) Let P0 �0�!p P1 �1�!p : : : �n�!p Pn+1 be a proved computation,and hereafter let i, as well as j, be either 0 or 1. Then, �n has a direct dependencyon �h (�h v12 �n) i� either� �h = �#h�0#0�0; �1#1�1i; �n = �2#2 and �#�i#i�i v1 �n; or� �h = �2#2 ; �n = �#h�0#0�0; �1#1�1i; �h v1 �#�i#i�i and �i is a send; or� �h = �#h�0#0�0; �1#1�1i; �n = �0#0h�00#00�00; �01#01�01i; �#�i#i�i v1 �0#0�0j#0j�0j ,and �0j is a send.The dependencies of �n are obtained by the re exive and transitive closure of v12,i.e., v2 = (v12)�.Infra-node causality is obtained as the re exive and transitive closure of the tworelations above, i.e. vn= (v1 [ v2)�:We now de�ne the relabelling function for infra-node causality.De�nition 4.3 (infra-node causality relabelling)Let � = P0 �0�! P1 �1�! : : : �n�! Pn+1 be a proved computation. Its associated infra-node causal computation NCt(�) is derived by relabelling any transition �k as nctk,where nctk = � � if `(�k) = �h`(�k); fh 6= kj�h vn �k; `(�h) 6= �gi otherwiseBelow is an example of the application of infra-node causality relabelling. Con-sider the programP0 = 2 jjj a:k ! v:bjjc:x ?:djjx jjj e:k?:f jjx !w:gjjx jjj2and its computationP0 jjj1jjj0jj0a�!p P1 jjj21jjj0jj0e�!p P2 jjj1hjjj0jj0k(v);jjj1jjj0jj0k(v)i�!p P3 (1)P3 jjj1jjj0jj1jj0c�!p P4 jjj21jjj0jj0f�!p P5 jjj1hjjj0jj1jj0x(w);jjj1jjj0jj1jj0x(w)i�!p P6P6 jjj1jjj0jj0b�!p P7 jjj1jjj0jj1jj0d�!p P8 jjj21jjj0jj1jj0g�!p P9The corresponding infra-node causality computation isP0 ha;;i�! P1 he;;i�! P2 ��! P3 hc;0i�! P4 hf;f0;1gi�! P5 ��! P6P6 hb;f0;1;3;4gi�! P7 hd;f0;1;3;4;6gi�! P8 hg;f0;1;4gi�! P9(the integer i in a set of causes refers to the transition Pi �i�! Pi+1).18

4.2 Intra-node causalityWe de�ne intra-node causality by interpreting the parallel structure of systems andprocesses. Therefore, we consider the pre�x of proof terms made up of jjji and jji.For the sake of readability, we follow the pattern of the de�nition of node causality.We de�ne two dependency relations and then we compose them to obtain intra-nodecausality.De�nition 4.4 (v3) Let P0 �0�!p P1 �1�!p : : : �n�!p Pn+1 be a proved computationand let �n = �0#0 0. Then, �n has a direct dependency on �h (�h v13 �n) i� either� �h = �# and �# is a pre�x of �0#0; or� �h = �#��00#00� and �00#00 is a pre�x of �0#0.The dependencies of �n are obtained by the re exive and transitive closure of v13,i.e., v3 = (v13)�.De�nition 4.5 (v4) The same as Def. 4.2 with v3 instead of v1.Intra-node causality is obtained as the re exive and transitive closure of the tworelations above, i.e. vp= (v3 [ v4)�:The intra-node causality relabelling is de�ned below.De�nition 4.6 (intra-node causality relabelling)The same as Def. 4.3 with vp instead of vn.Consider again computation (1). Its associated intra-node causal computationis P0 ha;;i�! P1 he;;i�! P2 ��! P3 hc;;i�! P4 hf;f0;1gi�! P5 ��! P6 hb;0i�! P7 hd;3i�! P8 hg;;i�! P9We conclude this section by comparing infra- and intra-node causality.Proposition 4.7 vp�vn.Proof. As far as the inclusion is concerned, we only need to prove that v13)v11. Thisfollows by noting that if �i#i is a pre�x of �j#j then �i = �j.Now consider the transition jjj1 jjj0 jj1 jj0c�! p of computation (1). It is the case thatjjj1jjj0jj0a vn jjj1jjj0jj1jj0c but jjj1jjj0jj0a 6vp jjj1jjj0jj1jj0c:Thus, the inclusion is strict.5 ExamplesIn this section we report some examples of causality semantics that deal with themain operators of Facile.In the following we introduce some helpful notation. When details of compu-tations are not important, we denote the operations performed by process bei asi; i0; : : :. The �gures only present the computations and the states of a Facile systemthat are interesting for the study at hand. Less signi�cant states are representedas �. To help the intuition on labels of transitions reported on the right-hand side19

of arcs, we sometimes add further information on the left-hand side of arcs. Thesyntax is 0operation0 ;. For examplenewnode(be0);# jjj1jjj0jjj1�jjj21�means that the transition is caused by the pre�x newnode(be0). This notation ismostly used for the internal actions because they all have a � label and are thereforenot distinguishable. We stress that the additional information is not generated bythe transition system and is not needed to derive non-interleaving semantics, but itis only added to simplify the interpretation of �gures.5.1 spawn(be) and activate code(be)Consider the program 1 jjj be0jjspawn(be1jjbe2):�jjbe3jjx jjj1It represents a system made up of only one node on which three processes arelocated. A set of its computations is depicted in Fig. 2.1 jjj be0jjspawn(be1jjbe2):�jjbe3jjx jjj1��1 jjj be00 jj(�jj(be1jjbe2))jjbe30 jjx jjj1� � � � �jjj1 jjj0 jj000jjj1 jjj0 jj21 jj030jjj1 jjj0 jj1 jj0�spawn;jjj1 jjj0 jj0000 �0 �1 �2 jjj1 jjj0 jj21 jj0300where�0 = jjj1jjj0jj1jj20� �1 = jjj1jjj0jj1jj0jj1jj010 �2 = jjj1jjj0jj1jj0jj2120Figure 2: A computation involving a spawn operation.Actions 000 and 300 depend on 00 and 30, respectively, because their labels are notmodi�ed during the execution of spawn(be1jjbe2).Furthermore, the actions �, 10 and 20 depend on spawn because its label (jjj1jjj0jj1jj0)is a pre�x of their labels (jjj1jjj0jj1jj0jj0, jjj1jjj0jj1jj0jj1jj0 and jjj1jjj0jj1jj0jj1jj1).Now we consider the set of computations of the program above in which activatecode(be1jjbe2) replaces spawn(be1jjbe2):� (Fig. 3).For the same reasons as in the previous example actions 000 and 300 depend on 00and 30, respectively, and actions 10 and 20 depend on activatecode.5.2 newnode(be)Consider the program 2 jjj newnode(be0):�jjx jjj be1jjx jjj2and its set of computations depicted in Fig. 4.20

1 jjj be0jjactivate code(be1jjbe2)jjbe3jjx jjj1��1 jjj be00 jj(be1jjbe2)jjbe30 jjx jjj1� � � �jjj1 jjj0 jj000jjj1 jjj0 jj21 jj030jjj1 jjj0 jj1 jj0�activate code;jjj1 jjj0 jj0000 �0 �1 jjj1 jjj0 jj21 jj0300where�0 = jjj1jjj0jj1jj2010 �1 = jjj1jjj0jj1jj0jj120Figure 3: A computation involving an activate code operation.2 jjjnewnode(be0):�jjx jjj be1jjx jjj23 jjj�jjx jjj be1jjx jjj be0jjx jjj3� �jjj1 jjj0 jj0�jjj31 jjj0 jj0�newnode(be0);jjj31 jjj0 jj0000 jjj1 jjj0 jj0�Figure 4: A computation involving a newnode operation.The action 00 is caused by newnode(be0) because the creation of a node is necessaryand in uences the occurrence of 00. The above relation is retrieved by looking atthe labels: the proof part on the right-hand side of the � in the newnode coincideswith that of 00. This is interpreted as a causal relation between the two actions.This relation is obtained by looking at the left-hand side of the � identifying theposition of the node which executes the operation. The action � is causally relatedto the newnode because its proof part coincides with the left-hand side of �.5.3 r spawn(e,be)Consider the program4 jjj newnode(be0):�jjx jjj r spawn(3; be1):�jjx jjj be2jjx jjj r spawn(3; be3): jjx jjj4and its set of computations presented in Fig. 5.The proof terms show that � depends on newnode(be0) because jjj0jj0 coincides withthe left-hand side of the label of newnode(be0). For the same reason, � dependson r spawn(3; be1). The transition labelled 200 depends on the transition labelled20 because they have the same proof part. r spawn(3; be1) causes 10 because theproof part of the latter transition coincides with the right-hand side of the former.Similarly, 30 is caused by r spawn(3; be3) and 00 is caused by newnode(be0). Finally,21

4 jjjnewnode(be0):�jjx jjjr spawn(3; be1):�jjx jjj be2jjx jjjr spawn(3; be3): jjx jjj4�5 jjj�jjx jjjr spawn(3; be1):�jjx jjj be20 jjx jjjr spawn(3; be3): jjx jjjbe0jjx jjj55 jjj�jjx jjj�jjx jjj (be20 jj(be1jjx)) jjjr spawn(3; be3): jjx jjjbe0jjx jjj55 jjj�jjx jjj�jjx jjj (be20 jj(be1jj(be3jjx))) jjj jjx jjjbe0jjx jjj5� � � � � � �jjj31 jjj0 jj020jjj1 jjj0 jj0�jjj51 jjj0 jj0�newnode(be0); jjj1 jjj0 jj0�jjj31 jjj0 jj1 jj0�r spawn(3;be1); jjj41 jjj0 jj0�jjj31 jjj0 jj21 jj0�r spawn(3;be3);jjj1 jjj0 jj0� �0 �1 �2 �3 �4 jjj51 jjj0 jj000where�0 = jjj21jjj0jj0� �1 = jjj31jjj0jj0200 �2 = jjj31jjj0jj1jj010�3 = jjj31jjj0jj21jj030 �4 = jjj41jjj0jj0 Figure 5: A computation involving an r spawn operation. depends on r spawn(3; be3) because its proof part coincides with the left-handside of the label of the r spawn.6 Analysis of a Mobile File Browser AgentThe following is a scaled down version of a problem with causal dependencies ofhigher order processes and mobile channels. It originally arose in the code forthe Mobile Service Agent demonstration given at the EITC'95 Exhibition. Using\traditional" debugging techniques it took two weeks to track down the problem.The problem is the following. We have an agent server that can be called todeliver a client (FB) to the user and leave behind a server (FTP). There is a mistakein the FTP server in the sense that it should have been recursive to handle severalcalls from the FB client. However, there is also a mistake in the overall system,namely that all client/server pairs share the same channel. Thus even though thereis a mistake in the FTP server, the system may continue to operate as long as werequest more FB clients. Indeed each time we request an FB client we generate anew FTP server which is waiting on the same channel, thus an old FB client may\steal" the new FTP server from a new FB client.Below we give the Facile code, both for running code (typewritten) in the FacileAntigua Release [32], and a version written in core Facile (italics). We omit parts notrelevant to our discussion. The system activates the two processes FBS and AC.Process AC is busy waiting for an agent request. When the request arrives, ACcreates a channel (reqch) and sends it to process FBS along their common channelgetch. Now process AC is waiting for an agent from FBS. Once the process FBShas received the channel name on which AC is waiting for the agent, FBS sends22

process FB to AC together with the needed channels. Then it activates an FTPserver on its node and restarts. Process AC activates the client FB on its nodeand resumes. Now the interaction is between FTP and FB as follows. The clientwaits for a request on channel getinfo, then creates the channel on which it wantsto receive the service (repch) and sends it to FTP. Then it waits for the service.The FTP server receives the channel on which it sends the answer to FB, thenprints a message to say that the connection is established and sends the answer. Atthis point the FTP server terminates. The FB client receives the answer, prints amessage to say that the interaction is �nished and reactivates itself. Since channelreqch is global and the client FB is a recursive process while FTP is not, theproblem described at the beginning of this section may arise. Note that even if theFTP server is made recursive, there would still not be the wanted correspondencebetween pairs of FTP servers and �le browsers FB.(* Declarations *)proc FB (getinfo,reqch) =let val _ = receive getinfo (* just to keep it waiting until asked *)val repch = channel ()val _ = send(reqch,repch)val _ = receive repchval _ = print "Got handshake from server\n"in activate FB (getinfo,reqch)end FB(getinfo;reqch)=getinfo?:(�repch:reqch!repch:repch?:FB(getinfo;reqch))channelproc FTP reqch =let val repch = receive reqchval _ = print "Request from client\n"in send(repch,());terminateend FTPreqch=(�repch:repch!:terminate)reqch?proc FBS (getch,reqch,getinfo) =let val fbch = receive getchval _ = send(fbch,FB(getinfo,reqch))val _ = spawn (FTP reqch)in activate FBS (getch,reqch,getinfo)end FBS(getch;reqch;getinfo)=(�fbch:fbch!FB(getinfo;reqch):spawn(FTPreqch):FBS(getch;reqch;getinfo))getch?proc AC (getag,getch) =let val _ = receive getag (* just to keep it waiting until asked *)val reqch = channel ()val _ = send(getch,reqch)val FBCagent = receive reqchin spawn FBCagent;activate AC (getag,getch)end AC(getag;getch)=getag?:(�reqch:getch!reqch:(�FBCagent:spawn(FBCagent):AC(getag;getch))reqch?)channel(* Body *)val getag = channel (): unit channel 23

spawn(FBS):spawn(AC)(spawn(AC)jjFBS)((terminatejjAC)jjFBS)...((terminatejj((ACjjFB2)jjFB1))jj((FBSjjFTP2)jjFTP1)) = s0��((terminatejj((ACjjFB2)jjFB1))jj((FBSjjFTP2)jjterminate)) = s1�...�jj0�hjj0 jj1 jj1reqch(repch);jj1 jj1reqch(repch)ijj1 jj1request client 1�1 hjj0 jj1 jj1repch;jj1 jj1repchi�2 hjj0 jj1 jj1reqch(repch);jj1 jj0 jj1reqch(repch)i�3 jj1 jj0 jj1request client 2�4Figure 6: A computation of the client-server system for mobile agents.val getinfo = channel (): unit channelletval reqch = channel ()val getch = channel ()in spawn (FBS (getch,reqch,getinfo));spawn (AC (getag,getch))end (�reqch:�getch:spawn(FBC(getch;reqch;getinfo)):spawn(AC(getag;getch)))channel)channelWe now show how the error in the �rst version of the system can easily besingled out by using a causal relation between transitions. The idea is that theoperations val = print "Request from client n" executed by any FTP server mustbe independent of one another. In fact, FTP serves and terminates. When theFB client interacts with two servers, thus leaving another client without its server,there is a chain of two actions and the �rst causes the second.As an example consider the computation in Fig. 6 extracted from the transitionsystem of the incorrect code. Assume that two FTP servers and two FB clientshave been activated, and that client FB1 steals the server of FB2.Intra-node causality establishes that�1 = jj1jj1 request client 1 vp jj1jj0jj1 request client 2due to the inheritance of causal dependencies through communications. Indeed,�3 vp �4 because the reader of �3 has the same proof part of �4; in turn, the writerof �3 depends on (the reader of) �2, hence �2 vp �3. Since �1 causes (the writer of)�2, we have �1 vp �2. By transitivity, �1 vp �4. This causal dependency makes themisuse of channels evident. 24

A �rst attempt to repair the error was to make FTP recursive through the codeproc FTP reqch =let val repch = receive reqchval _ = print "Request from client\n"in send(repch,());activate FTP reqchend FTPreqch=(�repch:repch!:activateFTPreqch)reqch?However, the same computation as in Fig. 6 can still occur, apart from states1 that now becomes equal to s0. This shows that FTP servers are not privateto FB clients. A way out is to make sure that each pair of FTP server and FBclient shares a private channel. It is implemented by replacing FTP by the aboverecursive version, and replacing FBS and the body byproc FBS (getch,getinfo) =let val fbch = receive getchval reqch = channel ()val _ = send(fbch,FB(getinfo,reqch))val _ = spawn (FTP reqch)in activate FBS (getch,getinfo)end FBS(getch;getinfo)=(�fbch:(�reqch:fbch!FB(getinfo;reqch):spawn(FTPreqch):FBS(getch;reqch;getinfo))channel)getch?and by, respectivelyval getag = channel (): unit channelval getinfo = channel (): unit channelletval getch = channel ()in spawn (FBS (getch,getinfo));spawn (AC (getag,getch))end (�getch:spawn(FBC(getch;getinfo)):spawn(AC(getag;getch)))channelNow it is straightforward to prove that a client FBi communicates with a serverFTPi along a private channel, generated by the same ith activation of FBS thatcreates FBi and FTPi. As any FTP has only one channel, it can serve only itsclient, and vice versa. Hence the problem has been solved and the bug has been�xed.Note that nothing has to be changed if there are more nodes in the system be-cause intra-node causality consider both process and system parallelism. However,to exemplify the generality of our parametric approach, we illustrate how locality se-mantics (see, e.g., [13, 7]) can be used to locate the fault component. Indeed, whilecausality makes evident the problem on the sharing of a global channel, localitypoints out the component which erroneusly interacts.We brie y introduce the new semantics and then we apply it to the runningexample with r spawn in place of spawn operations.Recently, many attention is paid to the ditribution of resources in concurrentdistributed systems, both theoretically and practically. Some semantics that nat-urally deal with this issue have been presented in the literature (see, e.g., [13, 7]).25

Essentially, they associates with each process in a system a location that can varydynamically. More precisely, when a process spawns some subprocesses, these areassigned a sublocation of their parent. These semantics can be useful to determinethe load of a given node in a system and also for debugging purposes. Indeed, whena bug show up, it is easy to detect the location of the process that performed theincorrect action. In this section, we de�ne a locality semantics for Facile in the styleof [13].Facile can express the distribution of processes on nodes. As a consequence,some notions of locality naturally arises, depending on the granularity of locations.Inter-node locality considers transitions at the node level by assuming that the in-ternal structure of each node is sequential. This assumption corresponds to havinguniprocessor nodes. Infra-node locality is an extension of inter-node locality intro-ducing the parallel structure of processes. This is the case of multiprocessor nodesand it is the semantics that we study in this paper. Hereafter, let 2 A [ f��#�g.Finally, recall that locality semantics studies the distribution in space of activitiesand thus it is insensible to silent transitions. Hence, we simply ignore communica-tions.Infra-node locality is obtained by considering both the parallel structure of nodesand the parallel structure of processes.De�nition 6.1 (infra-node locality) Let P0 �0�!p P1 �1�!p : : : �n�!p Pn+1 be aproved computation and let �n = �0#0 0. Then, �n has a direct infra-node localitydependency on �h (�h v1ploc �n) i� �h = �# and �# is a pre�x of �0#0.The infra-node locality dependencies of �n are obtained by the re exive and transi-tive closure of v1ploc, i.e., vploc = (v1ploc)�.Note that a process may have sub-processes. Thus, the check whether the processP is placed in a sub-location of another process Q is implemented by checking ifthe address of Q is a pre�x of the address of P . Accordingly, the actions of P willdepend of the ones of Q.The mistake can easily be singled out by using a locality relation between tran-sitions. With the same relation we also detect which are the faulty components.The idea is that the actions of the partners of an FTP server in the communica-tions must be locality related. This amounts to say that an FTP server alwayscommunicates with the same FB client.Now consider the computation in Fig. 7 extracted from the transition system ofthe incorrect code. It is the scaled down version of one of the computations thatshowed up a bug during the European IT Conference Exhibition in Brussels, 1995.Assume that two FTP servers and two FB clients have been activated, and thatclient FB1 steals the server of FB2.Infra-node locality establishes that�1 = jjj1jj1 reqch(repch) 6vploc jjj1jj0jj1 reqch(repch)The intuitive meaning of the above relation is that two di�erent FB clients requestservices from the same FTP server in transitions �1 and �2. This violates theinvariant of the system that FB/FTP pairs are strictly related. From the labelpre�xes jjj0jjj1jj1, jjj1jj1 and jjj1jj0jj1 we see that the components in question areFTPi and FBi.Now it is straightforward to prove that a client FBi communicates with a serverFTPi along a private channel, generated by the same ith activation of FBS thatcreates FBi and FTPi. As any FTP has only one channel, it can serve only itsclient, and vice versa. Hence the problem has been easily detected and solved. Nowis only a clerical matter going back to the original code made up of about 6K FacileAntigua lines and �x the bug. 26

r spawn(newnode; FBS):r spawn(newnode; AC)(r spawn(newnode; AC)jjjFBS)((terminatejjjAC)jjjFBS)...((terminatejjj((ACjjFB2)jjFB1))jjj((FBSjjFTP2)jjFTP1)) = s0��((terminatejjj((ACjjFB2)jjFB1))jjj((FBSjjFTP2)jjFTP1)) = s1�...�jjj0�hjjj0 jjj1 jj1reqch(repch);jjj1 jj1reqch(repch)i�1 jjj1 jj1request client 1hjjj0 jjj1 jj1repch;jjj1 jj1repchihjjj0 jjj1 jj1reqch(repch);jjj1 jj0 jj1reqch(repch)i�2 jjj1 jj0 jj1request client 2Figure 7: A computation of the client-server system for mobile agents.7 Analysing of a prefetch pipeline processorIn this section we report another application of the causality semantics to debugspeci�cation of distributed systems. In particular, we consider here hardware ar-chitectures.We describe a prefetch pipeline processor by letting any of its logical componentsbe processes connected through the parallel composition operator. The interactionbetween the components of the processor in the fetch-execute cycle are representedby communications between processes that reduces to fetch an instruction and thento execute it.The processor is made up of three components: an instruction unit IU, a bu�erQIE and an execution unit EU. It interacts with a memory M to fetch instructions.The intended behaviour of the processor PP is as follows. The IU module fetchan instruction from M and pass it to QIE and resumes. Module EU take the �rstinstruction available from QIE, executes it and then restarts.This kind of architecture improves performance of conventional processors be-cause one can overlap the time of fetch and execution of instructions. The speci�-cation of the system consisting of PP and M in Facile follows.proc M (f,i) = send(f,i);activate M (f,i)proc IU (f,c) = let val i = receive fin send(c,i);activate IU (f,c)endproc EU e = let val s = receive e 27

in send(s,());activate EU eendproc QIE_0 (c,e) = let val x = receive cin activate QIE1 (c,x)endand QIE_1 (c,e,x) =let val y = receive cin activate QIE_2 (e,x,y)end\%send(e,x);activate QIE_0 (c,e)and QIE_2 (e,x,y) = send(e,x);activate QIE_1 (c,e,y)(* Prefetch processor *)proc PP i =let val f = channel ()val c = channel ()val e = channel ()in activate M (f,i)||activate IU (f,c)||activate QIE_0 (c,e)||activate EU eendThe analysis that we carry out reveals a mistake in the sepci�cation of QIEoriginated by the nondeterministic choice %. Also in this case causality is essentialin showing the bug. Consider the following computation of our system depicted inFig. 8. M(f; i)jjIU(f; c)jjQIE0(c; e)jjEU(e)������hjj0fi;jj1 jj0fii�0 jj1hjj0ci;jj1 jj0cii�1 hjj0fi;jj1 jj0fii�2 jj1hjj0ci;jj1 jj0cii�4 jj21hjj0ex;jj1exi�5 jj31x�6Figure 8: A computation of the prefetch pipeline processor.28

The intuitive meaning of the transitions is as follows. The �rst transition is thefetch of an istruction (i1) from M, that IU passes to QIE through �1. The samecycle is repeated in the next two transitions where a new instructions is fetched(say i2). Finally, �6 represents the execution of i1. The bug in the speci�cation ismade evident by the causal dependency of the execution of i1 on the fetch of i2.Actually, �2 vp �3 because the input on channel f causes the output of the secondtransition. Similarly, �3 vp �4: Therefore, by transitive closure, we have�2 vp �4:As anticipated above, the dependency is introduced because there is no way todistinguish the ordering of fetching execution due to the % operator in the speci-�cation of QIE. Since % is a sequential operator, all the transitions of QIE occursat the same address and hence originates the same dependencies. We overcomethis problem by specifying QIE as follows, where a parallel composition replacesnondeterminism.proc QIE_1 (c,z) = let val x = receive cin send(z,x);activate QIE_1 (c,z)endproc QIE_2 (z,e) = let val x = receive zin send(e,x);activate QIE_1 (z,e)endproc QIE_0 (c,e) = let val z = channel ()in activate QIE_1 (c,z)||activate QIE_2 (z,e)endNow the same computation above no more raise the bug.8 ConclusionIn this paper we have presented a new operational semantics for the Facile pro-gramming language based on the notion of proved transition systems. From thissemantics it is possible to derive many di�erent types of information. In particu-lar, we have used the semantics to derive information about causal dependencies inFacile programs. The framework is applied to a case study derived from a success-ful demonstration of agent programming in Facile. Also, we have de�ned a localitysemantics that takes into account the distribution of processes on processors.Other types of information may be derived from the proved semantics and thesewere not needed for the analysis presented in this paper. Some of these are studiedin [5, 26].The proved semantics for Facile is an interesting example of what can be achievedwith a programming language based on strong formal foundations since it allows theformal reasoning about properties to be related directly to the running program andthus eliminates the model/running programgap that normally exists in systems withformal speci�cations, but implementations in traditional programming languages.Furthermore, since the proved semantics for Facile is based on \normal" tran-sition system de�nitions (although the labels carry a lot more information) it ispossible to (re)-use existing veri�er tools like CWB [9] and YAPV [3]. In particular,the latter has been used to derive the proved computations used here, and to handlethe long wired labels mechanically. 29

References[1] K. Ahlers, D. E. Breen, C. Crampton, E. Rose, M. Tucheryan, R. Whitaker, andD. Greer. An augmented vision system for industrial applications. In SPIE Photonicsfor Industrial Applications Conference Proceedings, October 1994.[2] R. Amadio, L. Leth, and B. Thomsen. From a concurrent �-calculus to the �-calculus.In Proceedings of FCT'95, 1995. Full version in technical report ECRC-95-18.[3] A. Bianchi, S. Coluccini, P. Degano, and C. Priami. An e�cient veri�er of trulyconcurrent properties. In V. Malyshkin, editor, Proceedings of PaCT'95, LNCS 964,pages 36{50. Springer-Verlag, 1995.[4] M. Boreale and D. Sangiorgi. A fully abstract semantics of causality in the �-calculus.In Proceedings of STACS'95, LNCS. Springer Verlag, 1995.[5] R. Borgia. Semantiche causali per FACILE. Master's thesis, Dipartimento di Infor-matica, Universit�a di Pisa, 1995.[6] G. Boudol and I. Castellani. A non-interleaving semantics for CCS based on provedtransitions. Fundamenta Informaticae, XI(4):433{452, 1988.[7] G. Boudol, I. Castellani, M. Hennessy, and A. Kiehn. A theory of processes withlocalities. Theoretical Computer Science, 114, 1993.[8] N. Busi and R. Gorrieri. A Petri net semantics for �-calculus. In I. Lee and S.A.Smolka, editors, Proceedings of CONCUR'95, LNCS 962, pages 145{159. Springer-Verlag, 1995.[9] R. Cleaveland, J. Parrow, and B. Ste�en. The concurrency workbench: A semantics-based tool for the veri�cation of concurrent systems. ACM Transaction on Program-ming Languages and Systems, pages 36{72, 1993.[10] Ph. Darondeau and P. Degano. Causal trees. In Proceedings of ICALP'89, LNCS372, pages 234{248. Springer-Verlag, 1989.[11] P. Degano, R. De Nicola, and U. Montanari. A partial ordering semantics for CCS.Theoretical Computer Science, 75:223{262, 1990.[12] P. Degano and C. Priami. Proved trees. In Proceedings of ICALP'92, LNCS 623,pages 629{640. Springer-Verlag, 1992.[13] P. Degano and C. Priami. Causality for mobile processes. In Proceedings of ICALP'95,LNCS 944, pages 660{671. Springer-Verlag, 1995.[14] Felix Gallo. Agent-Tcl: A white paper. Posted to the safe-tcl@cs.utk.edumailinglist, December 1994. Draft document.[15] A. Giacalone, P. Mishra, and S. Prasad. Facile: A symmetric integration of concurrentand functional programming. International Journal of Parallel Programming, 18:121{160, 1989.[16] A. Giacalone, P. Mishra, and S. Prasad. Operational and algebraic semantics forFacile: A symmetric integration of concurrent and functional programming. In Pro-ceedings ICALP'90, LNCS 443, pages 765{780. Springer-Verlag, 1990.[17] James Gosling and Henry McGilton. The Java language environment. White paper,May 1995. Sun Microsystems, 2550 Garcia Avenue, Mountain View, CA 94043, USA.Available at http://java.sun.com/.[18] L. Jategaonkar. Observing "True" Concurrency. PhD thesis, MIT, 1993.[19] L. Jategaonkar Jagadeesan and R. Jagadeesan. Causality and true concurrency: Adata- ow analysis of the �-calculus. In Proceedings of AMAST'95, LNCS 936, pages277{291. Springer-Verlag, 1995.[20] L. Leth and B. Thomsen. Some Facile Chemistry. Formal Aspects of Computing,Volume 7, Number 3, pages 314{328, 1995.[21] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes (I and II).Information and Computation, 100(1):1{77, 1992.30

[22] R. Milner, J. Parrow, and D. Walker. Modal logics for mobile processes. TheoreticalComputer Science, 114:149{171, 1993.[23] U. Montanari and M. Pistore. Concurrent semantics for the �-calculus. In ElectronicNotes in Computer Science, number 1. Elsevier, 1995.[24] G. Plotkin. A structural approach to operational semantics. Technical Report DAIMIFN-19, Aarhus University, Denmark, 1981.[25] V. Pratt. Modelling concurrency with partial orders. International Journal of ParallelProgramming, 15:33{71, 1986.[26] C. Priami. Enhanced Operational Semantics for Concurrency. PhD thesis, Dipar-timento di Informatica, Universit�a di Pisa, March 1996. Available as Tech. Rep.TD-08/96.[27] J.-P. Talpin. The Calumet Experiment in Facile - A Model for Group Communicationand Interaction Control in Cooperative Applications. Technical Report ECRC-94-26,European Computer-Industry Research Centre, 1994.[28] J.-P. Talpin, P. Marchal, and K.: Ahlers. Calumet - A Reference Manual. TechnicalReport ECRC-94-30, European Computer-Industry Research Centre, 1994.[29] B. Thomsen, F. Knabe, L. Leth, and P.-Y. Chevalier. Mobile agents set to work.Communications International, July 1995.[30] B. Thomsen, L. Leth, and A. Giacalone. Some Issues in the Semantics of FacileDistributed Programming. In Proceedings of the 1992 REX Workshop on \Semantics:Foundations and Applications", LNCS 666. Springer-Verlag, 1992.[31] B. Thomsen, L. Leth., F. Knabe, and P.-Y. Chevalier. Mobile agents. TechnicalReport ECRC-95-21, European Computer-Industry Research Centre, 1995.[32] B. Thomsen, L. Leth, S. Prasad, T.-M. Kuo, A. Kramer, F. Knabe, and A. Giacalone.Facile Antigua Release Programming Guide. Technical Report ECRC-93-20, Euro-pean Computer-Industry Research Centre, 1993.[33] James E. White. Telescript technology: The foundation for the electronic market-place. General Magic white paper, 2465 Latham Street, Mountain View, CA 94040,1994.[34] G. Winskel. Petri nets, algebras, morphisms and compositionality. Information andComputation, 72:197{238, 1987.31