A proposal to merge Multiple TupleSpaces, Object Orientation, andLogic ProgrammingVincenzo Ambriola Giovanni A. CignoniLaura SeminiDipartimento di InformaticaUniversit�a di PisaAbstractWe de�ne a new language that naturally satis�es the requirementsof concurrency support, modularity, and declarativity. Although someclasses of existing languages already cover a subset of this require-ments, there is no example of a programming language entirely ful�ll-ing them.We propose to merge three programming paradigms, Multiple Tu-ple Spaces, Object Orientation, and Logic Programming, as a solutionto our requirement list. Each paradigm is well characterized and satis-�es one of the given requirements. Moreover, we claim that the merg-ing will reveal new directions in the inception and the development offuture programming languages.1 IntroductionA programming language should be conceived for writing computer pro-grams. In the Oikos Project [13] there was the need for a powerful languageto implement the cooperation policies that rule the software developmentprocess.Starting from these assumptions, three years ago we decided to designa new language. During this enterprise we realized that our language could1

ful�ll the needs of a community of users larger than the group of researchersinvolved in writing software process programs in the Oikos Project.According to the principles of Software Process Modelling [8], cooperationpolicies should be expressed in a high level language that exhibits threeproperties: modularity, reusability, and concurrency support (possibly witha distributed implementation). From a more general point of view, theseneeds are shared by builders of large distributed systems.Our previous experience with languages based on Multiple Tuple Spacesled us to de�ne a strategy to simultaneously satisfy our requirements. Theoutcome of our quest was the idea to merge the Multiple Tuple Spacesparadigm with two other programming paradigms: Object Orientation andLogic Programming.We also discovered some useful side e�ects that derive from the merg-ing. For instance, dynamicity is a natural result of applying the ObjectOrientation perspective to the Multiple Tuple Spaces concept, and the useof uni�cation (from Logic Programming) rather than pattern matching, forassociative access to tuples, improves the declarativity of the language.In the following sections we present our requirements (Section 2) andthe programming paradigms that we choose to ful�ll them (Section 3). InSection 4 we describe the computational model obtained by merging theseparadigms. Then we present eta, the programming language that instantiatesthe proposed model (Section 5), its syntax (Section 6), and some semanticissues (Section 7). In Section 8 we discuss related works.2 Requirements for a languageOur goal is to satisfy the needs of the programmer who will use the languageto build large distributed software systems, as is the case in process-centeredsoftware development environments. Towards this aim, we design a program-ming language that ful�lls a strict list of requirements. We want our languageto be concurrent, modular, and declarative.2.1 ConcurrencyA concurrent language or, more precisely, a language that naturally supportsconcurrency must provide: 2

� syntactic constructs to de�ne autonomous entities of computation, i.e.,the processes, that can be executed in true parallelism;� mechanisms for process synchronization and cooperation; these mech-anisms may belong either to the share approach, where processes referto a common storage and synchronize by writing and reading on it, orto the communicate approach, where processes synchronize by sendingand waiting for messages.The expressive power of a concurrent programming language depends onthe mechanisms that the language provides to describe concurrent compu-tations without using operating system calls. To control the inherent non-determinism of concurrent computations, a concurrent language should alsoprovide mechanisms to express priority and mutual exclusion.Parallelism is di�erent from concurrency. For instance, a sequential lan-guage may have a parallel implementation that increases the performance ofprogram execution still preserving the semantics. By the way, a concurrentlanguage is the needed tool to implement parallel algorithms and distributedsystems.The large growth of local area networks is shifting the focus from central-ized to distributed architectures. Moreover, distribution can be viewed as anexternal constraint in the development of concurrent systems, i.e., when it ispractically impossible to share memory. Although shared memory can alwaysbe implemented on a distributed environment, using a communication basedlanguage that naturally supports distribution is an evident advantage. Fromthis point of view, in our requirement list concurrency covers the suitable fordistributed applications issue.2.2 ModularityAmodular system is made of a collection of logically autonomous entities, themodules, connected by a simple framework. Modularity is the key to develop-ing large systems, to improving maintenance, and to supporting reuse. Thisde�nition, with the listed bene�ts, well applies to software process programstoo.� A module must be a syntactic entity of the language. The implemen-tation of the language must support separate compilation of modules3

and dynamic loading of pre-compiled modules.� The language must support information hiding. Each module declaresa private part (used to keep the state of the module) and a public part(the interface) as the mean to express the interaction with the othermodules of the system.� The language must provide explicit constructs to de�ne the moduleinterface. The interaction mechanisms must refer to a well de�nedsemantic schema, e.g., procedure call or message passing.In our requirement list, modularity mainly covers the suitable for large pro-grams issue.Several aspects of modularity can be viewed under the concurrency per-spective. The modular design of a software system often elicits the existingparallelism and identi�es modules with concurrent entities. This approach,combined with a dynamic loading capability, suggests a dynamic languagefor the implementation of open systems, a language such that entirely newcomponents can be added without halting the running system. Moreover,dynamic loading can be enhanced by distribution or load balancing options.2.3 DeclarativityA programming language is declarative if its programs describe the resultsof a computation rather than the way such results are achieved, or, in otherwords if the programmer can write \what" he/she wants and not \how" toget it [12].In some cases this property may be a limitation, e.g., when the program-mer's task is to implement \something" (a data structure, an algorithm, awhole system) given in a procedural way. In general, however, declarativityis an advantage for the programmer and for this reason, in our requirementlist, declarativity covers the usable for programmers issue. In particular,we believe that this property is very useful when the programming goal isto build a concurrent application. In these cases, it is essential to describeevents and reactions, since the procedural alternative would be to explicitlyreceive external inputs, test complex multiple conditions, and produce properoutputs. 4

3 Programming language paradigmsOur quest for a language suitable for Software Process Modelling startedwith the design, the implementation, and the experimentation of MultipleTuple Spaces based languages [13]. Recently we formulated an elegant andnatural strategy to satisfy the requirements imposed by our research in Soft-ware Process Modelling [3]. We decided to investigate on the advantages ofmerging the Multiple Tuple Spaces paradigm with Object Orientation andLogic Programming. Each of these paradigms is well characterized and fullysatis�es one of the requirements listed above.3.1 Multiple Tuple SpacesConcurrent languages based on the Tuple Space paradigm exploit the sharedmemory approach. The store (i.e., the tuple space) is a multiset of tuplesthat represents the computation state. Autonomous computational entities,called agents, cooperate by reading and writing on the tuple space [5].The presence of some speci�c con�gurations of the tuple space causes theagents to react with a transition. A transition is described by a rule, i.e., aguarded action on the tuple space, a computation, and a write operation onthe tuple space.A guarded action is a read or a read-and-delete operation associativelyperformed on the tuple space. The computation is purely functional, withoutside e�ects on the tuple space. Since the behaviour of the agents depends onthe state of the tuple space, the tuple space and its agents can be seen as aclosed reactive (to its own state) system.The Multiple Tuple Spaces paradigm is a far-reaching extension of theTuple Space paradigm: a system is composed of a set (in some cases a hier-archy [7]) of tuple spaces, instead of a single one. Tuples are sent throughthe system from one tuple space to another, exploiting explicit addressing.Tuple spaces are reactive components of a distributed system (they do notshare anything). As in Tuple Space paradigm they react to changes to theirstate, but in this case, the state can be modi�ed by external messages too.This extension orthogonally combines the shared memory and the mes-sage passing paradigms, providing a powerful model to develop large systemsas collections of components. Programming languages based on Multiple Tu-ple Spaces include Linda-3 [10], ESP [7], and Pat�e [4]. A model dealing with5

both these aspects provides two grains of parallelism: coarse grained par-allelism between the tuple spaces, and �ne grained parallelism between theagents belonging to each component. Each form of parallelism refers to aprecise cooperation model: message passing and shared memory.These features, both with respect to the parallelism grain and to thecooperation models, resemble multitasking implementations commonly usedin the last generation of operating systems, like heavyweight and lightweightprocesses in Mach [16].3.2 Object OrientationThe Object Orientation paradigm formalizes the notions of class of objects,information hiding, inter-objects interaction policies, and inheritance. Theyall refer to the wider concept of modular programming.� The notion of class is an extension of the primitive concept of type. Theprocedures to operate on data structures belong to the type de�nition.The assignment of abstract names to collections of data and operationsis the �rst step to achieve modularity.� A module (a class) must hide the details of its internal implementationfrom the other components of the system ...� ... o�ering only a de�ned interface to its functionalities. The interfaceestablishes which functionalities are public, which are private, whichare restricted to a subset of the other components.� The development of new modules by extension and rede�nition of ex-isting ones is a powerful tool to build highly structured programs andto reuse existing software.Far from being a \silver bullet", Object Orientation is the best paradigmto support adaptation and maintenance, two issues of actual interest andresearch in software development [14] and, of more interest for us, in softwareprocess programming.6

3.3 Logic ProgrammingLogic Programming is one of the most advanced and re�ned approaches forsolving complex programming problems. It comes from the synergism be-tween logic (declarativeness) and programming (procedurality) [17, 12]. Therole of logic is to provide a formal framework to de�ne the semantics of pro-grams and to make them more understandable. The role of programmingis to deal with the computational aspects of programs and, from the logi-cians' point of view, to control how the proof (i.e., the program execution)proceeds.Logic programming couples the power of a single inference rule (reso-lution) with an extremely general form of pattern matching (uni�cation).Prolog is the most successful realization of this computational model.4 Merging the paradigmsOur idea is to specialize the object oriented model to the case of MultipleTuple Spaces languages, treating a tuple space and its agents as a uniqueprogramming entity (an object).4.1 Logic Programming + Multiple Tuple Spaces : : :The combination of tuple spaces with logic programming yields a paradigmthat well integrates cooperation and declarativity. Shared Prolog [5] belongsto this model, whose characteristics are:� a tuple is a logical fact, a Prolog atom, and the interaction between thetuple space and the agents is controlled by the uni�cation algorithm;� a restricted set of Prolog (with no side e�ects on the tuple space andon the Prolog knowledge base) is used to perform the functional com-putation associated to each rule.The expressive power of a tuple space language is enhanced by uni�cation:agent descriptions can include complex conditions on the tuple space, yetexpressed in a very concise manner. The cooperation and the computationfacets of an agent (the interaction with the tuple space and the computation7

�red by the speci�ed con�gurations of the tuple space, respectively) can beuniformly described by the same formalism.ESP and Pat�e are two examples of languages that extend the single tuplespace of SP to the Multiple Tuple Spaces paradigm. A common feature ofthese languages is the ability to write (send) tuples to other tuple spaces.Pat�e also provides a declarative way to control rule �ring sequences insideagents by means of path expressions [4].4.2 : : :+ Object Orientation : : :Objects provide an interface that, in a context where objects are concur-rent entities, is the speci�cation of the interaction with other objects of thesystem.As a concurrent object, the interface of a tuple space is de�ned by thetuples accepted as input and those produced as output. In our model, weprevent unexpected tuples from reaching a tuple space using uni�cation (fromLogic Programming) to control which tuples can pass through the declaredobject interface.Wiyh respect to inheritance, we follow the approach to de�ne new tu-ple spaces by extending their interface and rede�ning part of the rules thatspecify the object behaviour.4.3 : : := etaWe have shown how three independent programming models can be mergedin a new paradigm. The appealing features of this merging prompted us tomake the new paradigm concrete by de�ning a programming language. Thelanguage eta (Everything buT Assignment) is a Multiple Tuple Spaces andLogic language that borrows the programming style of the object orientedparadigm [3].In de�ning eta, our goal is the design of a language for the developmentof large, real, and distributed systems. Consequently, we take into accountthe notions of control and reliability. For instance, considering the commu-nications between tuple spaces, we want to detect whether either data willeventually reach their destination or the communication failed, e.g., becauseof an address error, an error of the support, or a violation of the input in-terface of the receiver. Similarly, we require primitives to express control8

information: sequencing, as well as alternation, priority, and mutual exclu-sion of agent actions. This requirement leads to a further improvement ofthe path expression mechanism already exploited in Pat�e.In the next section we present the characteristics of eta, showing both howit instantiates the proposed paradigm, and how it accomplishes our goal,enhancing control and reliability.5 The language etaA program in eta is a collection of class de�nitions, where each class de�nesthe behaviour of a set of possible objects.An object is an instance of a class. The state of an object consists of apassive part (a multiset of tuples) and an active part (a multiset of threads).Tuples have the form of Prolog atoms. Objects communicate by sending andreceiving messages, exploiting explicit addressing: messages are tuples addedto the receiver object's state, and addresses are object names. The event ofreceiving a message causes the incoming tuple to be added to the objectstate. This behaviour di�ers from that of most object oriented languageswhere the arrival of a message is interpreted as an operation or a procedureinvocation.5.1 Interface and information hidingIn eta each object provides an interface to the external world in terms ofthe tuples accepted as input from other objects and the tuples produced asoutput and sent through the system.class air company(Name)input freq(Name; ; ; ; )goutput fbooked( ; )g 9=; interface: : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : � private partThe name of a class is a term. The functor of the term identi�es the class,while the arguments are free variables (parameters of the class) that are9

instantiated when an object is activated. Input and output specify the tu-ples accepted as input, or sent to other objects, respectively. In the exam-ple, the object air company(c name) only accepts tuples that unify withreq(c name; ; ; ; ) and produces tuples of the form booked( ; ).Any message not accepted as input by the addressee raises a run-timeerror. The sender is acknowledged of this event. This mechanism is a simpleway to prevent unexpected tuples from reaching a tuple space. Moreover, asthe interface is the only visible and public part of an object, its behaviourcan be freely changed by keeping the interface invariant.5.2 Behaviour and controlThe behaviour of an object is de�ned by its threads. A thread is the orthogo-nal combination of rules and path expressions: rules describe actions in termsof reactive behaviour, path expressions express control on rules activations.A rule is composed of a guard, an outside computation, an interaction, anda postcondition.booking: rule namefreq( ; F light;N;R;C); in guardseats(F light; F ree)g guardmap(F light;M) read guardj commit operatorfind(N;R; Free;M; Seats; F ree0): body outsidefbooked(F light; Seats)g@C interaction computationfseats(F light; F ree0)g successbody fseats(F light; F ree); body failurereq(Fight;N; any; C)gtarget fseats(F light; F ree0); target failure postconditiontry later(C;F light; Seats)ginterface fseats(F light; F ree)g interfaceThe guard is a sequence of read (read guard) and input conditions (in guard):the former is a compound goal on the object state, the latter de�nes themultiset of atoms to be removed from the state. The outside computationhas no side-e�ects on the object state: the body de�nes a functional calculus;the interaction de�nes the tuples to be sent to external objects. Finally, thepostcondition de�nes a list of tuples to be written in the object state and the10

treatment of possible failures that occur during the execution of the body orof the interaction.In the example, the action described by rule booking is taken when arequest from a client C, for N places (R speci�es preferences, e.g., window),on ight number F light, is found. The tuple recording the number of freeseats on that ight is removed to be updated, while the map of the ightis only accessed in read mode. The body searches the requested seats. Incase of success, the booked acknowledgement is sent to the client. Otherwise,the request is reformulated, ignoring the preferences. Tuples in the targetor interface parts are written in the object state in case of failure of thecommunication with the client (see Sections 7.3.3 and 7.3.5).Path expressions are a declarative way to specify control and constrain a wildnon-determinism in rules activations [4]. According to this form of control,the activation of a rule is subjected to two conditions: it must satisfy pathexpression constraints, and the current state of the object must satisfy therule's guard. No backtracking on rule activations is allowed according to a\don't care" nondeterminism policy [15].A path expression is similar to a regular expression over the alphabet ofrule names, with the following exceptions:� a priority operator � extends the choice operator, allowing to expressa priority between two alternative paths;� an optionality construct is provided, as a shorthand for Exp j � (with �the empty path);� a failure operator rulefExp;Exp;Exp;Expg takes into account fourpossible di�erent outcomes of a rule evaluation (success or failure ofthe body and of the interaction).Path expressions can also specify semaphores (see Section 7.2).We extend our working example on the class air company( ), providingan example of thread:11

thread f thread namez }| {book : path expressionz }| {(list� bookingf�; booking; send; �g)� grules list : % deals with requests in the waiting listbooking : % as abovesend : % remove try later(: : :) and try to send againA thread terminates when it reaches the end of one of the (�nite) paths ofits path expression. When all the threads of an object are terminated, theobject terminates.5.3 Modularity and reusabilityA class de�nition can inherit from another one, exploiting an is-a declaration.class company(Name;Over)is-a air company(Name)output foverbooked( ; )g 9=; interface : extension: : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : � private part : overridingWe adopt an extensional avour of inheritance for the object interfaces, whilewe allow overriding for the object internal behaviour, uniformly with theencapsulation aspects of the language. An object can send and receive onlymessages that belong to a superset of those sent and received by an objectof the superclass, while reactions to an identical message can be di�erent.6 SyntaxIn this section we introduce the formal syntax of eta, using the BNF no-tation. The design choices made during the de�nition of the language havebeen oriented to modularity: a module corresponds to a syntactic entity andthe di�erent parts of each entity are loosely connected. Following this ap-proach, we split the de�nition of eta in three parts, each described in thenext three subsections. In Subsection 6.1 we give the general structure of a12

class de�nition, leaving unde�ned the production rules for threads and rules.They will be provided in Subsections 6.2 and 6.3, respectively.Syntactic categories are capitalized. The symbols ::= and j belong to theBNF notation, while f g [ ] ( ) ; : ; : j @ �� � + � belong to the language.Few syntactic categories are not capitalized and not expanded, for those werefer to the standard Prolog syntax.Keywords of eta, as well as primitives, are in boldface. The former setincludes: class, is-a, input, output, contents, initial, critical, threads, rules,with, end, body, interaction, and target; the latter includes: getlist, putset,new, not, father, and self.6.1 ClassesIn the next �gure we provide the syntax for the most general class de�nition.Actually, a class de�nition can be a proper subset of the listed parts (onlyclass and end are always required), with the following constraints: in thecase of class de�nition by inheritance, is-a is mandatory; at least init, thread,rules, and one among input, output, and contents must be speci�ed whende�ning an entirely new class.Variables appearing as parameters in a class name can bind variablesappearing in all the parts but contents, output, and with. In contents andoutput we allow only free atoms, as we want to statically verify if they meetrule postcondition or interaction; atoms in input can contain variables boundto the class parameters, or constants.The set of atoms that represent the object initial state and the set ofinitial threads, i.e., those activated with the object, are speci�ed by initial.A critical region speci�es a set of atoms and is identi�ed by a name thatranges over the alphabet of the semaphores.When a class is derived from another one, say A is-a B, the parts input,output, contents, and initial of the two classes are disjoint: in A we simplyde�ne the extentions with respect to B. On the other hand, we allow theoverriding of rules, threads, critical regions, and Prolog clauses (predicatede�nitions).13

ClassDefinition ::= class ClassNameis-a ClassNameinput fAtomsgoutput fFreeAtomsgcontents fFreeAtomsginitial InitialState ; fThreadNamesgcritical fCritical gthread fThreadsgrules Ruleswith prolog programendClassName ::= TermAtoms ::= Atom jAtoms ;AtomsFreeAtoms ::= FreeAtom j FreeAtoms ; FreeAtomsInitialState ::= f g j f Atoms gThreadNames ::= ThName j ThreadNames ; ThreadNamesCritical ::= Semaphore : f Atoms g j Critical ; CriticalThName ::= constantSemaphore ::= constantTerm ::= termAtom ::= atomFreeAtom ::= free atom6.2 ThreadsA thread consists of a name and a path expression. We de�ne the syn-tax of path expressions using three syntactic categories: Rname, Exp, andSemaphore. Rname denotes a rule name, Exp a path expression, andSemaphore a semaphore name: the grammar generates the set of path ex-pressions over the alphabet of rule and semaphore names.

14

Threads ::= ThName : Exp j Threads ; ThreadsExp ::= � % emptyj RName % rule namej Exp� % iterationj Exp Exp % sequencingj Exp j Exp % choicej Exp�Exp j Exp�Exp % priorityj Exp��Exp j Exp��Exp % 00j [ Exp ] % optionalityj ( Exp ) % precedencej RName f Exp ;Exp ;Exp ; Exp g% failurej Semaphore+Exp Semaphore� % critical regionRName ::= constant6.3 RulesA rule has a name and two parts separated by the commit operator j. Bothparts can be empty.Rules ::= Rule j Rules RulesRule ::= r�: % empty rulej RName : Guard j Post %normal rulej RName :Guard jj RName : j PostThe �rst part, Guard, is the rule guard. The second, Post, is a conjunctionof the outside computation and the postcondition of the rule.Guard ::= f Ingj Readj f IngGuardj Readf IngGuardIn ::= Atom j Get j In ; InRead ::= Atom j Get j PrologPrim j EtaPrim j Read ; ReadGet ::= getlist(Atom ; X) j getlist(Atom ; X ; PrologPrim)PrologPrim ::= Atom=Atom j Atom ?=Atom j : : : (n= == is var : : :)EtaPrim ::= self(X) j father(X) j notAtomX ::= variable 15

Both Read and In are sequences of atoms and Get primitives. The readguard (Read) may contain both eta primitives (EtaPrim) and primitivesderived from Prolog (PrologPrim), to express relations between the facts ofthe guard. Post ::= BodyInteractionSuccessFailBodyFailInteractionFailTargetBody ::= � j Atom:Interaction ::= � j Out@Term j new(Term) j Interaction InteractionSuccess ::= � j Out j ThName j Success SuccessFailBody ::= � j bodyfAtomsgFailInteraction ::= � j interactionfAtomsgFailTarget ::= � j targetfAtomsgOut ::= fAtomgj putset(X)j putset(X;Atom)j putset(X;Atom; PrologPrim)Post consists of the body, the interaction, and the postcondition. The body(Body) is a Prolog atomic atom. Interaction is a sequence of send (@) andactivations of new objects (new(Term)). The postcondition consists of aSuccess followed by the parts FailBody, FailInteraction, and FailTarget.Success is a sequence of write declarations (atoms or sets of atoms to bewritten on the object state) and thread activations. Expressions of the kindputset( ) specify lists of atoms.7 SemanticsAn eta system is a set of executing objects that are dynamically created.System execution consists in the concurrent execution of the objects, i.e.,the evaluation of the rules de�ned in the object class, according to the con-straints expressed by the path expression of every thread occurrence. Rules16

in di�erent thread occurrences are evaluated concurrently. A strong fairnessproperty on rule selection is guaranteed, according to the results presentedin [9].7.1 Interface: synchronization and reliabilityAt the semantic level, we model the interaction between two objects as fol-lows: after sending a message, either the message reaches the destinationor a failure in the communication is acknowledged. This synchronizationconstraint has a very low impact on the system parallelism and representsa su�cient condition to build reliable systems. Moreover, exploiting pathexpressions, we can force the sender of a message to wait for an answer toits request. Synchronous communications can be easily programmed.Communication between objects can fail: the addressee may not exist orit may not consider an incoming message as a possible input. The dynamiccharacteristics of etamake impossible to detect these failures at compile-time:they are handled by the run-time support of the language.7.2 Behaviour: threadsA thread de�nes all the feasible sequences of actions. A path expression as-sociated with each thread de�nes alternation, sequencing, and priority con-straints on rule activation, while the rules de�ne the reactive behaviour ofactions. Path expressions can also de�ne semaphores: atoms speci�ed ina critical region cannot be consumed by other threads than the one whichentered the critical region. Critical regions are especially needed when thepredicate getlist is involved in the guard of a rule.In the next subsection we show, by means of examples, how to derive apartial order over the set of rule names by making priorities explicit, whilein Section 7.2.2 we de�ne a �nite state machine that recognizes a path ex-pression.According to those de�nitions we say that a rule r, which occurs in a pathexpression p, can be evaluated in a state (s1; s2), where s1 is the state of theobject and s2 is the state of the �nite state machine that recognizes p, if:(1) the rule guard is satis�ed in s1 (see Section 7.3);(2) there is an outgoing edge from s2 labeled r;17

(3) r is maximal, with respect to the partial order induced by the priorities,in the poset of rules satisfying (1) and (2).Multiple occurrences of the same rule can appear in a path expression. Wede�ne a map that uniquely renames each occurrence of a rule name in thepath expression. In the next subsections we assume that path expressionsare properly renamed.7.2.1 PrioritiesWe call S the function that de�nes the partial order (over rule names) inducedby the priority operators of a path expression.S : Exp ::= 2Exp�Exp| {z }partial orderAlthough the de�nition of S is out of the scope of this paper, for the sake ofcompleteness in the presentation of eta we provide the following examples:S((a � b) � c) = f(a; b); (c; a); (c; b)gS(�+ab � c � d� � e�� �+fg� � h��)= f(d; e); (c; a); (c; d); (c; e); (g; h)g

r cr ar brb rf ra r c�� @@r dr e r gr h7.2.2 Finite state machineA deterministic �nite state machine that corresponds to a path expression isbuilt in two steps: �rst the path expression is translated into an equivalent(de�ning the same set of paths) regular expression, according to the mappingde�ned in the next �gure, then the �nite state machine that corresponds tothe regular expression is constructed [2].18

exp1 � exp2 �! exp1 j exp2exp�1 � exp2 �! exp�1 exp2exp�1 � exp2 �! exp�1 exp2[exp] �! exp j �rfexp1; exp2; exp3; exp4g �! rsuccexp1 j rbodyexp2 j rtargetexp3 j rinterfaceexp4sem+ exp sem� �! (sem+; r�) exp (sem�; r�)7.3 Rule evaluationThe evaluation of a rule is sequentially performed in four atomic steps: guard,body, interaction, and postcondition evaluation.7.3.1 Guard evaluationThe guard evaluation is de�ned by:eval : Guard� � �! 2��SThe function eval takes a rule guard (let call In the in-guard and Rd theread-guard), and the current object state �, and returns the set of pairs(�0; �) satisfying:� 8A 2 Rd: 9B 2 � s.t. A� is an instance of B;� 8 getlist(A;L) 2 Rd. L� = list of atoms in � unifying with A�;� 8 getlist(A;L;G) 2 Rd. L� = list of atoms C in � such that9�0: C�0 = A��0 and ` G��0;� ` G�, for every Prolog primitive G 2 Rd;� �� �0 and�0 = generalization of In�]fB s.t. member(B;L�) withgetlist(A;L) 2 In and A� unifies withB orgetlist(A;L;G) 2 In; 9�0:B�0 = A��0; and ` G��0gwith ] multiset union; �0 is the multiset of atoms that mustbe removed from the store;� no atom in � uni�es with A� for :A 2 Rd;19

� self(O) 2 Rd ) O� is the name of the object where the ruleis executed;� father(O) 2 Rd ) O� is the name of the object that activatedthe one where the rule is executed;� � does not bind any variable appearing only in a negated atom;� given a choice C of atoms of the object state unifying with theguard, � is the restriction, to the variables of the guard, of themost general uni�er of C and the guard itself.Note that because of the non-determinism in the selection of the atoms in thestore, di�erent choices of atoms can lead to di�erent unifying substitutions.If the outcome of eval is the empty set, then the guard is not satis�ed,while if it is satis�ed, a pair (�; �0) is selected and the guard is executed.7.3.2 Body evaluationBody evaluation is a standard Prolog evaluation of the atom in the body(instantiated with the substitution produced by the guard evaluation) withrespect to the Prolog program associated with the object. Body evaluation isan outside computation without side e�ects on the tuple space and withoutmodifying the knowledge base of the Prolog program (assert and retractprimitives are not allowed). Possible outcomes of the body evaluation areeither success (the �rst computed success substitution) or fail. Only in caseof success the resulting substitution binds the variables of the postcondition.7.3.3 Interaction evaluationThe interaction is evaluated only if the evaluation of the body is successful.Let �g and �b be the substitutions computed by guard and body evaluation,respectively, then interaction is instantiated by �g�b and then executed. Eachinteraction consists either of the communication to an external object or ofthe creation of a new object. The whole interaction is successfully executedif and only if it is possible to execute all its interactions.A communication fails for a target failure (the target object is not reach-able because it does not exist, the communication channel is interruped, orthe host is down) or for an interface failure (the target exists, but it does not20

accept the tuples sent because of a violation of its interface). The creation ofa new object fails if the required physical resources are not available (targetfailure) or if none of the classes in the library matches the request (interfacefailure).7.3.4 Putset primitivesSpecial attention must be given to the primitives putset(L), putset(L;A),and putset(L;A;G). The atoms written in the object state are: in the �rstcase those contained in list L; in the second case only those unifying with A;in the third case the atoms in L both unifying with A and satisfying goal G.7.3.5 Postcondition evaluationPostcondition evaluation depends upon the outcome of body and interactionevaluations. We distinguish four possible cases:� Successful evaluation of body and interaction: the success part of thepostcondition is instantiated by �g�b (outcomes of guard and body eval-uation, respectively) and executed;� Failure in the evaluation of the body: the body part of the postconditionis instantiated by �g and executed (the interaction is not executed);� Successful evaluation of body and target failure of the interaction: thetarget part of the postcondition is instantiated by �g�b and executed;� Successful evaluation of body, no target failure, but an interface failureof the interaction: the interface part of the postcondition is instanti-ated by �g�b and executed.8 Related worksWe present and discuss some programming paradigms that integrate two outof the three models we merged. Then, we brie y present the Actors model,that derives from the Object Oriented model and that shows some similaritieswith the paradigm we propose. 21

8.1 Logic Programming & Object OrientationLogic languages, and in particular Prolog, are not modular as they do notsupport reusability and information hiding. Moreover, they are not wellsuited to distributed problems, nor can they deal with an explicit notion ofstate. In models merging logic programming and object-orientation theselimitations are partly overcome [6]. An object is a logical theory (a setof clauses) and a method is a clause. According to these choices, inputand output method parameters are not statically de�ned, but dynamicallydetermined using uni�cation. More than one de�nition can be associated toeach method and the correct method is singled out by using backtracking.Objects communicate by message passing and a message is the request toevaluate a goal. Inheritance relation is interpreted as combination of logictheories.The merging of Logic Programming and Object Orientation well inte-grates declarativity and modularity. However, systems built in this modelare not history-sensitive and are still unable to deal with a notion of systemstate.8.2 Object Orientation & Multiple Tuple SpacesIn the object oriented model, an object communicates with other objects,while in the tuple space model an agent (thread) communicates with otheragents through the tuple space. In the object oriented model an object has toreact, with a method invocation, to the received messages, while in MultipleTuple Spaces an agent can react, with a transition, to the received tuples(temporal decoupling).An existing proposal of integration of these two paradigms de�nes a newcommunication model where tuple spaces are dynamically created objectsthat communicate by sending tuples [11]. However, there is no concreteexample of a programming language nspired by this model.8.3 ActorsThe computational model that we present in this paper shares many charac-teristics with the Actors model. An actor is \a computational agent whichhas a mail address and a behavior. Actors communicate by message pass-22

ing and carry out their actions concurrently" [1]. The communication isasynchronous, unless otherwise speci�ed.The main di�erence between the two paradigms relies on the receive pol-icy. Actors have an associated bu�er for incoming messages, which are pro-cessed one at a time. In Multiple Tuple Spaces, on the contrary, incomingmessages are added to the state of the receiving object and are accessed in anassociative way. This feature enhances the expressive power of the paradigm,as the reaction to a message can be contrained, in a uniform and declarativemanner, to other conditions of the state, exploiting the uni�cation algorithmand the atomicity of the guard evaluation.9 ConclusionsWe have identi�ed the requirements of concurrency support, modularity, anddeclarativity for a language suited to describe cooperation and, more gen-erally, to build large distributed systems. We have proposed the mergingof Multiple Tuple Spaces, Object Orientation, and Logic Programming as auniform paradigm that satisfy our requirements. Moreover, each paradigmsati�es one of the listed requirements and their merging does not a�ect thisproperty. Our claim is that the resulting programming paradigm will besuited for building large distributed applications according to the principlesof high level programmming.The language eta is a concrete example of language inspired to thisparadigm. The implementation of a compiler and a distributed run-timesupport for eta is now the focus of our research.AcknowledgementsWe would like to thank Angela Discenza for her contribution to the de�nitionof eta. We also thank the people of the Concurrent Systems Group at theWashington University, St.Louis, for their helpful suggestions.23

References[1] G. Agha. Actors: a Model of Concurrent Computation in Distributed Systems. TheMIT Press, Cambridge, Mass., 1986.[2] A.V. Aho, R. Sethi, and J.D. Ullman. Compilers: Principles, Techniques and ToolsAddison Wesley Publishing Company, 1986.[3] V. Ambriola, G. A. Cignoni, and L. Semini. eta - Everything buT Assignment. Proc.of the 1994 Joint Conference on Declarative Programming GULP-PRODE'94, vol.II, pages 132-146, 1994.[4] V. Ambriola and L. Semini. Control Speci�cation in Tuple Space Based Languages.Technical Report 19-93, Dipartimento di Informatica, Universit�a di Pisa, 1993.[5] A. Brogi and P. Ciancarini. The Concurrent Language Shared Prolog. ACM Trans-actions on Programming Languages and Systems, 13(1):99-123, 1991.[6] A. Brogi, E. Lamma, and P. Mello. Objects in a Logic Programming Framework.In Proc. of the First Russian Conference on Logic Programming, A. Voronkov (ed),volume 592 of Lecture Notes in Arti�cial Intelligence, pages 102-113. Springer-Verlag,Berlin, 1991.[7] A. Bucci, P. Ciancarini, and C. Montangero. A Distributed Logic Language Basedon Multiple Tuple Spaces. Proc. of the Logic Programming Conference, Tokio, 1991.[8] A. Finkelstein, J. Kramer, and B. Nuseibeh (eds). Software Process Modelling andTechnology. Research Studies Press, John Wiley & Sons, Taunton 1994.[9] M. Gaspari and L. Semini. Fairness in Logic Languages based on Shared Datas-pace. Proc. of the ICLP'93 Post-Conference Workshop on Blackboard-Based LogicProgramming, 1993.[10] D. Gelernter. Multiple Tuple Spaces in Linda. Proc. of the Parle 89, volume 365 ofLecture Notes in Computer Science. Springer-Verlag, Berlin, 1989.[11] S. Kawai and S. Matsuoka. Using Tuple Space Communication in Distributed Object-Oriented Languages. Proc. of the OOPSLA '88, pages 276-283, 1988.[12] R. Kowalski. Logic for Problem Solving. North-Holland, 1979.[13] C. Montangero. and V. Ambriola. Oikos: Constructing Process Centred SDEs. InSoftware Process Modelling and Technology, A. Finkelstein, J. Kramer, and B. Nu-seibeh (eds), Research Studies Press, John Wiley & Sons, pages 131-161, Taunton,1994. 24

[14] D. C. Rine, B. Bhargava. Object Oriented Computing. IEEE Computer, 25(10):6-10,1992.[15] E. Y. Shapiro. The Family of Concurrent Logic Programming Languages. ACMComputing Surveys, 21(3):412-510, 1989.[16] A. Tevanian, R. F. Rashid, D. B. Golub, D. L. Black, E. Cooper, and M. V. Young.Mach Threads and the Unix Kernel: The Battle for Control. Proc. of the USENIXAssociation Conference, 185-197, Phoenix, 1987.[17] D. S. Warren. Memoing for Logic Programs. Communications of ACM, 35(3):93-110,1992.

25