Denis Darquennes
email: denis.darquennes@unamur.be

Orcid : 0000´0001´7259´08371

Jean-Marie Jacquet
email: jean-marie.jacquet@unamur.be

Orcid : 0000´0001´9531´05191

Isabelle Linden
email: isabelle.linden@unamur.be

On Multiplicities in Tuple-based Coordination Languages : the Bach Family of Languages and its Expressiveness Study

Building upon previous work by the authors, this paper reviews and proposes extensions of Linda-like languages aiming at coordinating data-intensive distributed systems. The languages manipulate tokens associated in different ways with a notion of multiplicity. Thanks to De Boer and Palamidessi's notion of modular embedding, we establish expressiveness hierarchies. We also discuss implementation issues and argue that the more expressive the language is the more expensive is its implementation.

Introduction

Technological evolutions over the last recent years have confirmed the upward trends in pervading our everyday environment by more and more numerical artifacts, mobile or not, injecting or retrieving an endless increasing amount of information. As a result, service-oriented applications have become more and more necessary and indeed have been developped at an increasing speed. Most of them are based on popularity and quality measures, with, as a key feature, the fact that these meseasures are not determined at specific points in time but rather continuously, as user experiences evolve.

Moreover, with the help of machine learning techniques, data tend to be more and more transformed in knowledge, which leads our daily life to be more and more mediated by knowledge systems. In this context coordinating systems relying on a huge amount of data appears to be a central task. Coordination languages and models have proved to be well suited to program the interaction of conventional distributed systems, and in particular to model service-oriented applications (see eg [START_REF] Bravetti | Service Oriented Computing from a Process Algebraic Perspective[END_REF][START_REF] Jongmans | Automatic Code Generation for the Orchestration of Web Services with Reo[END_REF][START_REF] Tolksdorf | Laura -A Service-Based Coordination Language[END_REF]). Recently, it has been shown in [START_REF] Mariani | Coordination of Complex Sociotechnical Systems -Self-organisation of Knowledge in MoK[END_REF] how they can be used to code complex socio-technological systems based on the interaction of knowledge intensive components. This paper aims at addressing a more fundamental issue in exploring how the addition of multiplicity information to tuples increases the expressiveness of Linda [START_REF] Gelernter | Generative Communication in Linda[END_REF], the seminal coordination language, while being able to handle the above mentioned requirement of popularity and quality measures.

To do so, we shall start with a dialect of Linda developed at the University of Namur, named Bach. Following Linda, it permits to model in an elegant way the interaction between different components through the deposit and retrieval of tuples in a shared space. As its basic form only allows the manipulation of one tuple at a time and since the selection between several tuples matching a required one is provided in a non-deterministic fashion, a first extension was proposed in [START_REF] Jacquet | On Density in Coordination Languages[END_REF] in the aim of enriching traditional data-based coordination languages by a notion of multiplicity (historically named density) attached to tuples, thereby yielding a new coordination language, called Dense Bach. In a second extension we have proposed in [START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF] to consider lists of tuples among which densities are distributed. The resulting language has been named DBD-Bach. It turns out that its presentation can be made more elegant by using a variant, named VD-Bach, in which arguments of coordination primitives are composed of lists of so-called dense tokens.

Introducing variants of languages necessarily calls for a gain of expressiveness. Based on previous work by the authors, among others of [START_REF] Brogi | Modeling Coordination via Asynchronous Communication[END_REF][START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF][START_REF] Brogi | On Modeling Coordination via Asynchronous Communication and Enhanced Matching[END_REF][START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF][START_REF] Jacquet | On Density in Coordination Languages[END_REF][START_REF] Linden | On the Expressiveness of Timed Coordination Models[END_REF], we shall employ de Boer and Palamidessi's modular embedding and show that Bach is less expressive than Dense Bach, which itself is less expressive than VD-Bach. VD-Bach being similar in essence to multiset rewriting, as introduced in Gamma [START_REF] Banâtre | Programming by multiset transformation[END_REF][START_REF] Banâtre | Gamma and the Chemical Reaction Model: Ten Years After. Coordination Programming[END_REF], we shall also compare the two languages and prove that Gamma is actually more expressive than VD-Bach.

Since our purposes are essentially of a theoretical nature, for simplicity purposes, we shall consider in this paper simplified versions of the languages where tuples are taken in their simplest form of flat and unstructured tokens. Nevertheless, as we shall argue at the end of the paper, the resulting simplification of the matching process is orthogonal to our purposes and, consequently, our results can be directly extended to more general tuples. Consequently, our languages will subsequently be renamed with a T suffix, thus yielding BachT, DBD-BachT and VD-BachT.

Despite this simplification, we shall also discuss implementation issues and, show, without big surprise, that the more expressive a language is the more expensive is its implementation. This highlights from another perspective the expressiveness results : instead of directly using the more expressive language, it is of interest from an efficiency point of view to use the language just expressive enough for coding purposes under consideration.

The rest of the paper is organized as follows. Section 2 presents the languages studied in the paper and defines an operational semantics. Section 3 evidences the interest of these languages through the coding of some examples but also by showing how the newly introduced language VD-BachT can express the language DBD-Bach introduced in [START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF]. Section 4 provides a short presentation of modular embedding and, on that basis, proceeds with an exhaustive comparison of the relative expressive power of the languages. Section 5 shows how these expressiveness results can be lifted to tuple-based languages. Section 6 discusses implementation issues. Finally, section 7 compares our work with related work, draws our conclusions and presents expectations for future work.

2 Densed Tuple-based Coordination Languages

Primitives

A. BachT and Dense BachT

Let us start by defining the BachT and Dense BachT languages ( [START_REF] Jacquet | On Density in Coordination Languages[END_REF]) from which the languages under study in this paper are extensions. The following definition formalizes how we attach a multiplicity or density to them. Definition 1. Let Stoken be a enumerable set, the elements of which are subsequently called tokens and are typically represented by the letters t and u. Define the association of a token t and a positive integer n P N as a dense token. Such an association is typically denoted as tpnq. Define then the set of dense tokens as the set SDtoken. Note that since Stoken and N are both enumerable, the set SDtoken is also enumerable.

Intuitively, a dense token tpmq represents the simultaneous presence of m occurrences of t. As a result, ttpmqu is subsequently used to represent the multiset tt, ¨¨¨, tu composed of these m occurrences. Moreover, given two multisets of tokens σ and τ , we shall use σ Y τ to denote the multiset union of elements of σ and τ . As a particular case, by slightly abusing the syntax in writing ttpmq, tpnqu, we have ttpmqu Y ttpnqu " ttpmq, tpnqu " ttpm `nqu. Finally, we shall use σ Z ttpmqu to denote, on the one hand, the multiset union of σ and ttpmqu, and, on the other hand, the fact that t does not belong to σ. The primitives of the BachT language are essentially the Linda ones rephrased in a constraint-like setting. As a result, by calling store a multiset of tokens aiming at representing the current content of the tuple space, the execution of the tellptq primitive amounts to enriching the store by an occurrence of t. The askptq and getptq primitives check whether t is present on the store with the latter removing one occurrence. Dually, naskptq tests whether t is absent from the store. The primitives of the Dense BachT language extend these primitives by simultaneously handling multiple occurrences. Accordingly, tellptpmqq atomically puts m occurrences of t on the store and askptpmqq together with getptpmqq require the presence of at least m occurrences of t with the latter removing m of them. Moreover, naskptpmqq verifies that there are less than m occurrences of t.

pTq x tellptq | σ y ÝÑ x E | σ Y ttu y pAq x askptq | σ Y ttu y ÝÑ x E | σ Y ttu y pGq x getptq | σ Y ttu y ÝÑ x E | σ y pNq t R σ x naskptq | σ y ÝÑ x E | σ y
pT d q m P N0 x tellptpmqq | σ y ÝÑ x E | σ Y ttpmqu y pA d q m P N0 x askptpmqq | σ Y ttpmqu y ÝÑ x E | σ Y ttpmqu y pG d q m P N0 x getptpmqq | σ Y ttpmqu y ÝÑ x E | σ y pN d q n ă m x naskptpmqq | σ Z ttpnqu y ÝÑ x E | σ Z ttpnqu y
These executions can be formalized by the transition steps of Figures 1 and2, where configurations are pairs of instructions, for the moment reduced to simple primitives, coupled to the contents of a store. Note that E is used to denote a terminated computation. As can be seen by the above description, the primitives of BachT are those of Dense BachT with a density of 1. Consequently, our explanation starts by the more general rules of Figure 2. Rule pT d q states that for any store σ and any token t with density m, the effect of the tell primitive is to enrich the current multiset of tokens by m occurrences of token t. Note that Y denotes multi-set union. Rules pA d q and pG d q specify the effect of ask and get primitives, both requiring the presence of at least m occurrences of t, but the latter also consuming them. Rule pN d q defines the nask primitive, which tests for the absence of m occurrences of t. Note that there might be some provided there are less than m. It is also worth observing that thanks to the notation σ Z ttpnqu one is sure that t does not occur in σ and consequently that there are exactly n occurrences of t. This does not apply for rules pA d q and pG d q for which it is sufficient to assume the presence of at least m occurrences, allowing σ to contain others.

Figure 1 specifies the transition rules for the primitives of the BachT language. As expected, they amount to the rules of Figure 2 where the density m is taken to be 1.

B. Vectorized Dense BachT

A natural extension is to replace a dense token by a set of dense tokens in the primitives. For instance, the primitive askptp1q, up2q, vp3qq would succeed on a store containing one occurrence of t, two of u and three of v. Dually, the computation of tellptp1q, up2q, vp3qq would result in adding one occurrence of t on the store, two of u and three of v.

The following definitions formalize this intuition. As seen above, to avoid using unnecessary brackets, we shall slightly abuse notations and use lists of dense tokens, which we shall subsequently designate as vectors of dense tokens, hence the name Vectorized Dense BachT or VD-BachT for short. The intuition remains however that of sets, with the order of the dense tokens being meaningless. Definition 3. Define a vector of dense tokens as a list t 1 pm 1 q, ¨¨¨, t n pm n q of dense tokens. Such a vector is subsequently denoted as ÝÝÑ tpmq. Define SVDtoken as the set of vectors of dense tokens. The transition steps for these primitives are defined in Figure 3. As suggested above, rule pT v q asserts that telling a vector of dense tokens amounts to adding each of them with the corresponding density on the store. Similarly, rule pA v q requires for an ask primitive to succeed the presence, for each token t i , of at least m i occurrences on the store. According to rule pG v q the behavior of a get primitive performs such a test for presence but also removes m i occurrences of t i on the store. Finally, rule pN v q requires, for each token t i , the absence of m i occurrences. It is here worth noting that, in contrast to BachT and Dense BachT, the behavior of the nask primitive is not the negation of that of the ask primitive. Indeed, this interpretation would have required for the nask primitive that, for some token t i , less than m i occurrences are present on the store. It will however be handful to have such a nask primitive. We thus introduce it, name it weak nask and denote it by wnask. It is formally defined by rule pW w q of Figure 4.

It is worth observing that with such a definition, wnaskp ÝÝÑ tpmqq succeeds whenever naskp ÝÝÑ tpmqq succeeds. However, the converse is not true. Consider, for instance, the store composed of 2 occurrences of t and 4 of u. In that context, naskptp1q, up5qq does not succeed since, although 4 ă 5 the inequality 2 ă 1 does not hold. However, wnaskptp1q, up5qq succeeds since, as multisets, ttp2q, up4qu Ę ttp1q, up5qu. Rephrased using the notation of rule pN v q, it is required for nask that p 1 ă m 1 ^¨¨¨^p n ă m n whereas wnask only requires that p 1 ă m 1 _ ¨¨¨_ p n ă m n . In view of that, it is easy to verify that wnaskpt 1 pm 1 q, ¨¨¨, t n pm n qq can be encoded as follows : naskpt 1 pm 1 qq `¨¨¨ǹ askpt n pm n qq where `denotes the non-deterministic choice. As a result, although useful later, wnask does not bring an increase of expressiveness.

C. MRT

The last language we shall consider is a Gamma-like language ( [START_REF] Banâtre | Programming by multiset transformation[END_REF][START_REF] Banâtre | Gamma and the Chemical Reaction Model: Ten Years After. Coordination Programming[END_REF]), based on the chemical reaction metaphor. It considers communication primitives as the rewriting of pre-condition multi-sets into post-condition multi-sets. Intuitively, the operational effect of a multi-set rewriting (pre,post ) consists in inserting all the positive post-conditions, and in deleting all the negative post-conditions from the current store σ, provided that σ contains all positive pre-conditions and does not meet any of the negative pre-conditions. Formally, these rewritings are specified as follows. T MR ::" ptM u, tM uq

M ::" λ | `t | ´t | M, M
where λ indicates an empty multi-set and where t denotes a token.

It is worth observing that not all pairs of preconditions and postconditions correspond to reasonable computations. Indeed, as stated above, it is possible to require in a precondition that the same token is present and absent or to require in the postcondition the removal of a token which has not been tested for presence in the precondition. We subsequently define such reasonable pairs of pre-and post-conditions as respectively consistent and valid. To that end, we first introduce some notations. Definition 6. Given a multi-set rewriting pair pP re, P ostq, denote by P re `the multi-set tt | `t P P reu of tokens positively appearing in the precondition and by P re ´the multi-set tt| ´t P P reu negatively appearing in it. Similarly, we shall denote by P ost `and P ost ´the multiset of tokens appearing positively and negatively in the postcondition.

A multi-set rewriting pair (Pre,Post) is said to be consistent if P re `XP re

´"

H. It is said to be valid if P ost ´Ď P re `.

A consequence of consistency and validity is that four basic pairs of pre-and post-conditions can be put forward: pt`tu, tuq, pt´tu, tuq, ptu, t`tuq, pt`tu, t´tuq. They correspond respectively to the askptq, naskptq, tellptq and getptq of the BachT language.

It turns out that it is possible to define it by one rule. To express it, an auxiliary notion is however needed. It extends the notations of Definition 6 to capture the fact that, for each token, the tokens mentioned negatively in the definition are not with their multiplicity on the current store σ. Definition 7. For any token t, define P re ´rts as the multiset of negatively marked tokens t in the precondition P re: P re ´rts " tt : ´t P P re ´u.

Given a precondition P re and a store σ, we then define the non element-wise inclusion operator K as follows: P re ´K σ iff P re ´rts Ę σ, for any token t.

With this notation, rule (CM) of Figure 5 states that a multi-set rewriting pP re, P ostq can be executed in a store σ if the multi-set P re `is included in σ and if no negative pre-condition occurs with the required multiplicity in σ. Under these conditions, the effect of the rewriting is to delete from σ all the negative post-conditions and to add to σ all the positive post-conditions.

Languages

We are now in a position to formally define the languages we shall consider in the paper. The statements of these languages, also called agents, are defined from the tell, ask, get and nask primitives by possibly combining them by the classical non-deterministic choice operator `, parallel operator (denoted by the || symbol) and the sequential operator (denoted by the ; symbol). The formal definition is as follows.

Definition 8. Define the BachT language L B as the set of agents A generated by the following grammar:

A ::" T b | A ; A | A || A | A `A
where T b represents a token-based primitive. Define similarly the Dense BachT language L DB , the VD-BachT language L V B , the MRT language L MR by taking instead of the token-based primitive T b , respectively the dense token-based primitives T db , the list of token-based primitive T vb and the multi-set rewriting primitive T MR . Moreover, subsequently, we shall consider sublanguages formed similarly but by considering only subsets of these primitives. In that case, if H denotes such a subset, then we shall write the induced sublanguages as L B pHq, L DB pHq, L V B pHq and L MR pHq respectively. Note that for the latter sublanguages, the tell, ask, nask and get primitives are associated with the basic pairs described above.

Transition system

To study the expressiveness of the languages, a semantics needs to be defined. As suggested in the previous subsections, we shall use an operational one, based on transition systems. For each transition system, the configuration consists of agents (summarizing the current state of the agents running on the store) and a multi-set of tokens (denoting the current state of the store). In order to express the termination of the computation of an agent, we extend the set of agents by adding a special terminating symbol E that can be seen as a completely computed agent. For uniformity purpose, we abuse the language by qualifying E as an agent. To meet the intuition, we shall always rewrite agents of the form (E; A), (E || A) and (A || E) as A. This is technically achieved by defining the The rules for the primitives of the languages have been given in Figures 1 to 5. Figure 6 details the usual rules for sequential composition, parallel composition, interpreted in an interleaving fashion, and non-deterministic choice.

pSq xA | σy ÝÑ xA 1 | σ 1 y xA ; B | σy ÝÑ xA 1 ; B | σ 1 y pPq xA | σy ÝÑ xA 1 | σ 1 y xA || B | σy ÝÑ xA 1 || B | σ 1 y xB || A | σy ÝÑ xB || A 1 | σ 1 y pCq xA | σy ÝÑ xA 1 | σ 1 y xA `B | σy ÝÑ xA 1 | σ 1 y xB `A | σy ÝÑ xA 1 | σ 1 y

Observables and operational semantics

We are now in a position to define what we want to observe from the computations. Following previous work by some of the authors (see eg [START_REF] Brogi | On the Expressiveness of Coordination Models[END_REF][START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF][START_REF] Linden | On the Expressiveness of Absolute-Time Coordination Languages[END_REF][START_REF] Linden | On the Expressiveness of Timed Coordination via Shared Dataspaces[END_REF][START_REF] Linden | On the Expressiveness of Relative-Timed Coordination Models[END_REF]), we shall actually take an operational semantics recording the final state of the computations, this being understood as the final store coupled to a mark indicating whether the considered computation is successful or not. Such marks are respectively denoted as δ `(for the successful computations) and δ ´(for failed computations). Definition 9.

1. Define the set of stores Sstore as the set of finite multisets with elements from Stoken. 2. Let δ `and δ ´be two fresh symbols denoting respectively success and failure.

Define the set of histories Shist as the cartesian product Sstore ˆtδ `, δ ´u. 3. For each language L I of the languages L B , L DB , L V B , L MR , define the operational semantics O I : L I Ñ PpShistq as the following function: for any agent

A P L OpAq " tpσ, δ `q : xA|Hy Ñ ˚xE|σyu Y tpσ, δ ´q : xA|Hy Ñ ˚xB|σy Û, B " Eu

Applications

To evidence the interest of Dense BachT and VD-BachT, let us turn to some applications and see how they easily allow for their encodings.

A simple taxi application

A typical service application inspired by Uber consists in a system allowing to select taxi drivers based on their reputation. To be operational, such a system needs on the one hand to allow users to express their satisfaction with regard to the service provided, and on the other hand, to test that a taxi driver is recognized at a sufficient level of satisfaction. For illustration purposes, we will assume that only positive marks are taken into account and that the service offered by a taxi driver can be evaluated as good or excellent, corresponding to a respective evaluation with numbers 1 and 2. We will then imagine that a level of satisfaction 100 is a minimal satisfaction mark for a reasonable driver.

Using Dense BachT for the first task, the satisfaction of a user can be registered by inserting the token taxi driver id once if the evaluation mark is good and twice if it is excellent. Technically, with taxi driver id being the identifier of the taxi driver, this amounts to respectively executing tell(taxi driver id(1)) or tell(taxi driver id(2)). As regards the second task, making sure that a proposed driver, say identified by id, has reached a level of satisfaction of at least 100, can be simulated by executing the primitive ask(id(100)). Note that, as the number of matching tuples is only counted, such a satisfaction level may be reached thanks to the contribution of many users. Of course, different policies can be implemented in the application, for instance to forbid a user to mark a taxi driver more than once a day. It is also worth noting that thanks to the space and time decoupling between information producers and information consumers offered by coordination languages, it is very easy to introduce new users and new taxi drivers in the application.

The dining philosophers

Formulated by Edsger Dijkstra in 1965, the dining philosophers is a classical concurrency problem addressing the synchronisation of processes sharing ressources. It is formulated as follows : N philosophers spend their time thinking and eating. To eat, they must sit on a round table in front of a dish and take the forks on their left and right sides. There is however only one fork between two dishes, which makes it impossible for all the philosophers to eat simultaneously.

The classical solution is to use semaphores, one for each fork and one to let only enter to the table a number of philosophers. Other solutions have been proposed by the coordination community, for instance, using Respect ( [START_REF] Omicini | Formal ReSpecT in the A&A Perspective[END_REF]). The Vector Dense BachT language proposes a very simple solution by associating each fork with a token and by simulating each philosopher taking his two forks by a get primitive on these tokens and dually each philosopher realising them by means of a tell primitive. For N " 5, the philosophers may then be coded as follows :

P hil 0 " getpf 0 , f 1 q; tellpf 0 , f 1 q; P hil 0 P hil 1 " getpf 1 , f 2 q; tellpf 1 , f 2 q; P hil 1 ¨¨P hil 4 " getpf 4 , f 0 q; tellpf 4 , f 0 q; P hil 4 with the whole set of philosophers simulated by P hil 0 || P hil 1 || P hil 2 || P hil 3 || P hil 4

An online shopping system

Let us now consider an online shopping system related to an European sporting goods store, present in five different European cities : Brussels, Paris, London, Berlin and Rome. All these shops propose the same articles. In order to manage efficiently the number of orders that arrive through the online system, these are distributed on the different shops present in the five cities. Assume that a group of 50 orders arrive and has to be distributed equally between the different shops. This can be simulated through the execution of the following tell primitive :

tell(Brussels [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF], Paris [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF], London [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF], Berlin [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF], Rome [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF]).

Assume now that the following maxima of orders to be processed have been imposed for the shops : 200 orders for Brussels, 75 for Paris, 50 for London, 150 for Berlin and 70 for Rome. A check whether these maxima have not been reached can be simulated by executing the following nask primitive : nask(Brussels(200), Paris(75), London(50), Berlin(150), Rome(70)).

Distributed density

In the online shopping problem, the arrival of 50 orders has been explicitly distributed on the shops. A natural extension is to let the execution of the primitive non-deterministically choose the distribution. We are then lead to consider a list of tokens together with a density and to distribute it on the tokens. The following definition formalizes such an association. Definition 10. Let Snlt denote the set of non-empty lists of tokens in which, for simplicity purposes, each token differs from the others. Such a list is typically denoted as L " rt 1 , . . . , t p s and is thus such that t i ‰ t j for i ‰ j. Define a dense list of tokens as a list of Snlt associated with a strictly positive integer. Such a dense list is typically represented as Lpmq, with L the list of tokens and m an integer.

The distribution of the density over a list of tokens is formalized through the following distribution function.

Definition 11. Define the distribution of tokens from dense lists of tokens to sets of tuples of dense tokens as follows:

Diprt 1 , ¨¨¨, t p spmqq " tpt 1 pm 1 q, ¨¨¨, t p pm p qq : m 1 `¨¨¨`m p " mu Note that, thanks to the definition of dense tokens, we assume above that the m i 's are positive integers. For the sake of simplicity, we shall call the set Diprt 1 , ¨¨¨, t p spmqq the distribution of m over rt 1 , ¨¨¨, t p s.

The distribution of an integer m over a list of tokens L has the potential to express the behavior of the BachT primitives extended with dense lists of tokens as arguments. Indeed, telling a dense list amounts to telling atomically the t i rm i s's of a tuple defined above. Asking or getting a dense list requires to check that a tuple of Diprt 1 , ¨¨¨, t p spmqq is present on the considered store. For the negative ask, the requirement is that none of the tuple is present. For the ease of writing and to make this latter concept clear, we introduce the following concept of intersection. Definition 12. Let m be a positive integer, L " rt 1 , ¨¨¨, t p s be a list of tokens and σ a store. We define DipLpmqq [ σ as the following set of tuples of dense tokens :

DipLpmqq [ σ " tpt 1 pm 1 q, . . . , t p pm p qq P DipLpmqq : tt i pm i qu Ď σu

We are now in a position to specify the language extension handling dense lists of tokens. Definition 13. Define the set of dense lists primitives T dbd as the set of primitives T dbd generated by the following grammar:

T dbd ::" tellpLpmqq | askpLpmqq | getpLpmqq | naskpLpmqq
where Lpmq represents a dense list of tokens.

The transition steps for these primitives are defined in Figure 7. As suggested above, rule pT dbd q specifies that telling a dense list Lpmq of tokens amounts to atomically adding the multiple occurrences t i pm i q's of the tokens of a tuple of the distribution of m over L. Note that the selected tuple is chosen nondeterministically, which gives to a tell primitive a non-deterministic behavior as opposed to the tell primitives of BachT and Vectorized Dense BachT. Rule pA dbd q states that asking for the dense list Lpmq amounts to testing that a tuple of the distribution of m over L is in the store, which is technically stated through the non-emptyness of the intersection of the distribution and the store. Rule pG dbd q requires that the tokens of the tuples are removed in the considered multiplicity. Finally, rule pN dbd q specifies that negatively asking Lpmq succeeds if m is strictly positive and no tuple of the distribution of m over L is present on the current store.

We are now in a position to define the language Dense BachT with a Distribution of the density over a list of tokens by considering the statements of this language as defined from the tell, ask, get and nask primitives possibly combined by the non deterministic choice, parallel and sequential operators.

A further extension consists in equipping the tokens of a dense list with minimal and maximal numbers, as follows.

Definition 14. Define the association of a token and two positive integers of N as a capacity dense token. Such a token is typically denoted as tpm, nq where t is the token and m, n are the integers. Definition 15. Let Snlct denote the set of non-empty lists of capacity dense tokens in which, for simplicity purposes, each token differs from the others. Such a list is typically denoted as L " rt 1 pm 1 , n 1 q, . . . , t p pm p , n p qs and is thus such that t i ‰ t j for i " j. Define a dense list of capacity dense tokens as a list of Snlct associated with a strictly positive integer. Such a list is typically represented as Lpmq, with L the list of capacity dense tokens and m an integer.

The expected extended language is simply obtained by slightly modifying the notion of distribution introduced in Definition 11.

Definition 16. Define the cardinality based distribution of tokens from dense lists of capacity tokens to sets of tuples of extended dense tokens as follows:

Dcprt 1 pm 1 , n 1 q, ¨¨¨, t p pm p , n p qspqqq " tpt 1 pq 1 q, ¨¨¨, t p pq p qq : q 1 `¨¨¨`q p " q and m i ď q i ď n i for i P t1, ¨¨¨, puu Note that nothing guarantees that the above set is non empty. We shall subsequently called coherent those dense lists of capacity based tokens such that their cardinality based distribution is non empty and restrict ourselves to such coherent dense lists in the following.

To conclude this section, it is worth observing that it is straightforward to translate the positive version of DBD-BachT and its cardinality extension in terms of VD-BachT.

Indeed, as easily observed, one can code the tell, ask and get primitives of DBD-BachT as follows :

tellpLpmqq " ÿ vPDipLpmqq tellpv r q askpLpmqq " ÿ vPDipLpmqq askpv r q getpLpmqq " ÿ vPDipLpmqq getpv r q where v r denotes the vector v restricted to its strictly positive dense tokens.

Translating the nask primitive is slightly more complicated in requiring the parallel composition of the weak form of nask of vectors:

naskpLpmqq " || vPDipLpmqq wnaskpv r q Translating the DBD-BachT language with cardinality proceeds similarly by using DcpLpmqq instead of DipLpmqq.

Expressiveness study

The translation just introduced evidences the need for a study of the expressiveness power of the languages introduced in Section 2, to which we now turn.

On the expressiveness of languages

A natural way to compare the expressive power of two languages is to determine whether all programs written in one language can be easily and equivalently translated into the other language, where equivalent is intended in the sense of conserving the same observable behaviors. According to this intuition, Shapiro introduced in [START_REF] Shapiro | Embeddings Among Concurrent Programming Languages[END_REF] a first notion of embedding as follows. Consider two languages L and L 1 . Assume given the semantics mappings (Observation criteria) S : L Ñ O s and S 1 :

L 1 Ñ O 1
s , where O s and O 1 s are on some suitable domains. Then L can embed L 1 if there exists a mapping C (coder) from the statements of L 1 to the statements of L, and a mapping D c (decoder) from O s to O 1 s , such that the diagram of Figure 8 commutes, namely such that for every statement A P L 1 : D c pSpCpAqqq " S 1 pAq. This basic notion of embedding turns out however to be too weak since, for instance, the above equation is satisfied by any pair of Turing-complete languages. De Boer and Palamidessi hence proposed in [START_REF] De Boer | Embedding as a Tool for Language Comparison[END_REF] to add three constraints on the coder C and on the decoder D c in order to obtain a notion of modular embedding usable for concurrent languages:

1. D c should be defined in an element-wise way with respect to O s , namely for some appropriate mapping D el @X P O s : D c pXq " tD el pxq | x P Xu (P 1 )

2. the coder C should be defined in a compositional way with respect to the sequential, parallel and choice operators:

CpA ; Bq " CpAq ; CpBq CpA || Bq " CpAq || CpBq CpA `Bq " CpAq `CpBq (P 2 )
3. the embedding should preserve the behavior of the original processes with respect to deadlock, failure and success (termination invariance):

@X P O s , @x P X : tm 1 pD el pxqq " tmpxq pP 3 )

where tm and tm' extract the termination information from the observables of L and L 1 , respectively.

An embedding is then called modular if it satisfies properties P 1 , P 2 , and P 3 . The existence of a modular embedding from L 1 into L is subsequently denoted by L 1 ď L. It is easy to prove that ď is a pre-order relation. Moreover if L 1 Ď L then L 1 ď L that is, any language embeds all its sublanguages. This property descends immediately from the definition of embedding, by setting C and D c equal to the identity function.

Comparing BachT, Dense BachT and Vectorized Dense BachT

The expressive power of the different sublanguages of BachT has been studied in [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF][START_REF] Brogi | On the Expressiveness of Coordination Models[END_REF][START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF] from which the expressiveness hierarchy of Figure 9 can be established. Building upon these results, the article [START_REF] Jacquet | On the Introduction of Density in Tuple-Space Coordination Languages[END_REF] has established the embedding relations of Figure 10.

In both figures, an arrow from a language L 1 to a language L 2 means that

L 2 embeds L 1 , that is L 1 ď L 2 . When an arrow from L 1 to L 2 has no counterpart from L 2 to L 1 , then L 1 is strictly less expressive than L 2 , that is L 1 ă L 2 . If L 1 ď L 2 and L 2 ď L 1 then L 1 and L 2 are equivalent, that is L 1 " L 2 .
In that case, they are depicted together. If L 1 ę L 2 and L 2 ę L 1 then L 1 and L 2 are not comparable with each other. This is subsequently denoted by L 1 ≀ L 2 . Thanks to the transitivity, both figures contain only a minimal amount of arrows. Apart from these induced relations, no other relation holds. It is worth noting that the hierarchy relations presented in Figure 9 appear in the center of Figure 10. This reflects the fact that BachT is a special case of Dense BachT. Moreover, the hierarchy of the Dense BachT sublanguages resembles that of the BachT sublanguages. This intuitively results from the very nature of the ask, nask and get primitives, which are not altered by the density of tokens. Nevertheless, except for the sublanguage reduced to a tell primitive, it is worth observing that the dense sublanguages are strictly more expressive than their BachT counterparts. This highlights the fact that Dense BachT is an extension of BachT bringing more expressiveness.

Following the same reasonings as those published in [START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF] it is possible to establish similar embedding relations between Dense BachT and Vectorized BachT. Due to space limits, the proof are not reproduced here but the results are depicted in Figure 11. To get a complete expressiveness picture, it remains to study the expressiveness of Vectorized Dense BachT and MRT. This is the purpose of the next subsection. Due to space limits, the key points are only given, the interested reader being referred to [START_REF] Darquennes | On Multiplicities in Coordination Languages[END_REF] where all the proofs are conducted in details.

Relating Vectorized Dense BachT and MRT

As a first observation, it is easy to establish that the VD-BachT sublanguages are embedded in the corresponding MRT sublanguages. and using the identity as decoder.

Proposition 1 L V B pχq ď L MR pχq,
As for the results mentioned before, we shall only consider non trivial sublanguages, namely sublanguages containing at least the tell primitive. The store being feeded with tokens, the second step is to provide the sublanguage with a possibility to question the store about the presence or the absence of tokens on it. Those two capacities result from the introduction of the ask and nask primitives. A third important property is then to allow the language to retrieve tokens from the store, by using the get primitive. Finally the last step studies the most complete language, combining the get and tell primitives with the nask and/or ask primitives.

A. Adding tokens on the store

When only constituted by the tell primitive the sublanguages are equivalent, namely L V B ptellq and L MR ptellq are equivalent. uq " tellppt 1 pm 1 q, ¨¨¨, t k pm k qqq.

B. Checking for presence and/or absence when adding tokens

In contrast to what is obtained in the comparison of Dense BachT and Vectorized BachT languages, L V B pask,tellq is as expressive as L MR pask,tellq.

Proposition 3 L V B pask,tellq " L MR pask,tellq
Proof. (i) On the one hand, L V B pask,tellq ď L MR pask,tellq, by Proposition 1.

(ii) On the other hand, L MR pask,tellq ď L V B pask,tellq is established by noting that any agent of L MR pask,tellq can be simulated by an agent of L MR paskq followed by an agent of L MR ptellq.

In contrast, L V B pnask,tellq is strictly less expressive than L MR pnask,tellq.

Proposition 4 L V B pnask,tellq ă L MR pnask,tellq.

Proof. (i) On the one hand, L V B pnask,tellq ď L MR pnask,tellq holds by Proposition 1. (ii) On the other hand, L MR pnask,tellq ę L V B pnask,tellq is proved by considering agent AB = pt´au, t`buq and agent BA = pt´bu, t`auq, with OpAB || BAq " tpH, δ ´qu. The proof proceeds by contradiction, by assuming the existence of a coder C with CpABq in normal form [START_REF] Brogi | On the Expressiveness of Linda-like Concurrent Languages[END_REF], and thus written as tellp Ý Ñ t 1 q; A 1 `¨¨¨`tellp Ý Ñ t p q; A p `naskp Ý Ñ u 1 q; B 1 `¨¨¨`naskp Ý Ñ u q q; B q . In this expression we will establish that there is no alternative guarded by a tellp Ý Ñ t i q operation and no alternative guarded by a naskp Ý Ñ u j q operation either, which is impossible since CpABq must contain at least one primitive. We notice that the coding of CpAB || BAq can be written as CpABq || CpBAq by P 2 .

Let us first establish that there is no alternative guarded by a tellp Ý Ñ t i q operation. Indeed if there is an alternative guarded, say by tellp Secondly we establish that there is no alternative guarded by a naskp Ý Ñ u j q operation. Indeed starting from the empty store, if there is an alternative guarded, say by naskp Ý Ñ u j q, then D " xCpAB || BAq|Hy Ñ xpB j || CpBAqq|tt i uy is a valid computation prefix of CpAB || BAq. It should deadlock afterwards since OpAB || BAq " pH, δ ´q. However D is also a valid computation prefix of CppAB || BAq `ptu, t`auqq. Hence, CppAB || BAq `ptu, t`auqq admits a failing computation which contradicts the fact that OppAB || BAq `ptu, t`auqq " ptau, δ `q.

Ý Ñ t i q, then D " xCpAB || BAq|Hy Ñ xpA i || CpBAqq|t Ý Ñ t i
L MR pask,tellq and L V B pnask,tellq are not comparable with each other, and so are L MR pnask,tellq and L V B pask,tellq.

Proposition 5 L MR pask,tellq ≀ L V B pnask,tellq
Proof. On the one hand, we have that L MR pask,tellq ę L V B pnask,tellq. Otherwise, by non embedding by transitivity, we have L V B pask,tellq ď L V B pnask,tellq which has been proved impossible (see Figure 11). On the other hand, L V B pnask,tellq ę L MR pask,tellq is established by contradiction. Indeed, assuming the relation holds, we would then have L B pnask,tellq ď L MR pask,tellq, which has been proved impossible in [START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF].

Proposition 6 L MR pnask,tellq ≀ L V B pask,tellq
Proof. On the one hand, L MR pnask,tellq ę L V B pask,tellq holds. Otherwise, by embedding by transitivity, we have L V B pnask,tellq ď L V B pask,tellq which is impossible (see Figure 11). On the other hand, L V B pask,tellq ę L MR pnask,tellq is established by contradiction by considering tellptp1qq ; askptp1qqq and by noting that Optellptp1qq ; askptp1qqq " tpttp1qu, δ `qu.

We now prove that L V B pask,nask,tellq and L MR pnask,tellq are not comparable with each other. (ii) The proof of L MR pnask,tellq ę L V B pask,nask,tellq is an extension of the proof used in Proposition 4 with normal forms extended with ask primitives. It is established by considering agent AB = pt´au, t`buq and agent BA = pt´bu, t`auq, with Oppt´au, t`buq || pt´bu, t`auqq " tpH, δ ´qu.

Let us now prove that L MR pask,tellq is strictly less expressive than L V B pask,nask,tellq.

Proposition 8 L MR pask,tellq ă L V B pask,nask,tellq
Proof. (i) On the one hand, thanks to Proposition 3, L MR pask,tellq " L V B pask,tellq ď L V B pask,nask,tellq and thus L MR pask,tellq ď L V B pask,nask,tellq.

(ii) On the other hand, L V B pask,nask,tellq ę L MR pask,tellq, since otherwise, L V B pnask,tellq ď L V B pask,nask,tellq ď L MR pask,tellq, which has been proved impossible in Proposition 5.

We now prove that L V B pask,nask,tellq is stricly less expressive than L MR pask,nask,tellq.

Proposition 9 L V B pask,nask,tellq ă L MR pask,nask,tellq Proof. (i) On the one hand, the fact that L V B pask,nask,tellq ď L MR pask,nask,tellq is immediate by Proposition 1. (ii) On the other hand, L MR pask,nask,tellq ę L V B pask,nask,tellq. Otherwise, by embedding by transitivity, from L MR pnask,tellq ď L MR pask,nask,tellq, one would get L MR pnask,tellq ď L V B pask,nask,tellq, which has been proved impossible in Proposition 7.

L V B pget,tellq is not comparable with L MR pask,tellq nor with L MR pask,nask,tellq.

Proposition 10 L V B pget,tellq ≀ L MR pask,tellq
Proof. See [START_REF] Darquennes | On Multiplicities in Coordination Languages[END_REF].

Proposition 11 L V B pget,tellq ≀ L MR pask,nask,tellq
Proof. On the one hand, for L V B pget,tellq ę L MR pask,nask,tellq, we refer the reader to [START_REF] Darquennes | On Multiplicities in Coordination Languages[END_REF]. On the other hand, L MR pask,nask,tellq ę L V B pget,tellq. Otherwise, by transitivity of the embedding, one would have that L MR pask,tellq ď L MR pask,nask,tellq ď L V B pget,tellq which has been proved impossible in Proposition 10.

L MR pask,tellq can be proved to be not comparable with L V B pnask,get,tellq nor is L MR pask,tellq.

Proposition 12 L MR pask,tellq ≀ L V B pnask,get,tellq ≀ L MR pnask,tellq Proof. See [START_REF] Darquennes | On Multiplicities in Coordination Languages[END_REF].

We are now in a position to establish that L V B pget,tellq is not comparable with L MR pnask,tellq.

Proposition 13 L V B pget,tellq ≀ L MR pnask,tellq
Proof. On the one hand, L V B pget,tellq ę L MR pnask,tellq. Otherwise, as L V B pask,tellq ă L V B pget,tellq, one would have L V B pask,tellq ď L V B pget,tellq ď L MR pnask,tellq which has been proved impossible in Proposition 6. On the other hand, L MR pnask,tellq ę L V B pget,tellq. Otherwise, we would have L MR pnask,tellq ď L V B pget,tellq ď L V B pnask,get,tellq which has been proved impossible in Proposition 12.

L V B pnask,get,tellq is not comparable with L MR pask,nask,tellq.

Proposition 14 L MR pask,nask,tellq ≀ L V B pnask,get,tellq Proof. (i) On the one hand L MR pask,nask,tellq ę L V B pnask,get,tellq. Otherwise, L MR pask,tellq ď L V B pnask,get,tellq which contradicts Proposition 12. (ii) On the other hand, L V B pnask,get,tellq ę L MR pask,nask,tellq. By contradiction, consider tellptp1qq ; getptp1qq. Opptellptp1qq ; getptp1qqq " tpH, δ `qu. Hence any computation of Cptellptp1qqq ; Cpgetptp1qqq is successful. Such a computation is composed of a computation for Cptellptp1qqq followed by a computation for Cpgetptp1qqq. As Cpgetptp1qqq is composed of ask, nask, tell primitives which do not destroy elements on the store, the latter computation can be repeated step by step which yields successful computation for Cptellptp1qqq ; pCpgetptp1qqq || Cpgetptp1qqqq. However, Optellptp1qq ; pgetptp1qq || getptp1qqq " tpH, δ ´qu.

C. Retrieving tokens from the store Proposition 15 L V B pget,tellq ă L MR pget,tellq Proof. See [START_REF] Darquennes | On Multiplicities in Coordination Languages[END_REF].

We can now prove that L MR pget,tellq is not comparable respectively with L V B pnask,tellq, L V B pnask,get,tellq and L V B pask,nask,tellq.

Proposition 16 L MR pget,tellq ≀ L V B pnask,tellq
Proof. On the one hand, L MR pget,tellq ę L V B pnask,tellq. Otherwise, L MR pask,tellq ď L MR pnask,tellq which has been proved impossible in [START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF]. On the other hand, L V B pnask,tellq ę L MR pget,tellq is established by contradiction, by considering tellptp1qq ; naskptp1qq. Indeed, one has Optellptp1qq ; naskptp1qqq " tpttp1qu, δ ´qu whereas it is possible to establish that Cptellptp1qqq ; Cpnaskptp1qqq has a successful computation.

Proposition 17 L MR pget,tellq ≀ L V B pnask,get,tellq
Proof. On the one hand, L MR pget,tellq ę L V B pnask,get,tellq. Otherwise, as L MR pask,tellq ď L MR pget,tellq, we then have L MR pask,tellq ď L V B pnask,get,tellq which has been proved impossible in Proposition 12. On the other hand, L V B (nask,get,tell) ę L MR pget,tellq. Otherwise, we would have L V B pnask,tellq ď L MR pget,tellq which has been proved impossible in Proposition [START_REF] Busi | A Process Algebraic View of Linda Coordination Primitives[END_REF].

Proposition 18 L MR pget,tellq ≀ L V B pask,nask,tellq
Proof. On the one hand, L MR pget,tellq ę L V B pask,nask,tellq. Otherwise, one has L MR pask,tellq ď L MR pget,tellq ď L V B pask,nask,tellq which has been proved impossible in Proposition 8. On the other hand, L V B pask,nask,tellq ę L MR pget,tellq. Otherwise, one would have L MR pask,tellq ď L MR pask,nask,tellq ď L V B pget,tellq which has been proved impossible in Proposition 10.

E. Summary

Figure 12 provides a summary of the expressiveness results developped in this paper in a three dimensional perspective. It is worth observing that the Vectorized Dense BachT language obeys the same hierarchy as the BachT, Dense BachT and MRT languages. This is due to the nature of the tell, ask, nask and get primitives, which is preserved by the extension provided to the tokens. It is also worth noting that the sublanguage reduced to the tell primitive has the same power in all the languages. The other sublanguages obey the expressiveness studies already developped for BachT and Dense BachT. Finally, the Vectorized Dense Bach sublanguages appear to be strictly more expressive than their Dense BachT counterparts but are strictly less expressive than their MRT counterparts. The notable exception is provided by the L V B pask,tellq sublanguage, which is as expressive as the L MR pask,tellq sublanguage. Note that, in the picture, the dash arrows are drawn to suggest the threedimensional perspective but have the same meaning as the plain arrows.

From tokens to tuples

As announced in the introduction, the paper has so far concentrated on token based versions of the languages. A natural question to ask is whether the expressiveness study performed in Section 4 can be extended to tuples and thereby can embrace Linda-like languages in their full version.

To that end, two issues need to be taken into account. On the one hand, structured pieces of information need to be tackled instead of flat tokens. Using our notations, this would lead to consider tuples of the form xt 1 , ¨¨¨, t n y instead of t as arguments of tell, ask, get and nask primitives. On the other hand, it is desirable to introduce variables as arguments of the tuples in ask, get and nask primitives to retrieve values from the tuples stored on the tuple space 3 . The resulting tuples are classically called templates or anti-tuples.

It turns out that tackling these issues can be reduced to using flat tokens by assuming a very reasonable hypothesis : variables have to range over enumerable sets of values. If this is the case, then, as exemplified in process algebras like mCRL2 [START_REF] Groote | Modeling and Analysis of Communicating Systems[END_REF], any primitive containing a tuple with variables can be rewritten as a choice of that primitive with the variables instantiated to values. For instance, askpx1, X : Intyq can be rewritten as ř iPInt askpx1, iyq. As a result, assuming a general choice over enumerable sets in the language, we may reduce the language to primitives involving tuples without variables. As a further step, tuples having a finite number of arguments and the choices being on enumerable sets, these tuples range over enumerable unions of enumerable sets, namely over an enumerable set. We may thus associate any of these tuples to a token of Stoken and vice-versa. By doing so, we are back to the token-based languages studied before, provided that an interpretation is given to dense tuples. Two are actually possible. Consider for instance a store containing twice tp1q, three times tp2q and one time tp3q. Then, in a first interpretation, the request askptpX : Intqp3qq can be satisfied if one may instantiate X to an integer, say i, such that the induced instance tpiq appears at least three times on the store. In our example, this would be possible by giving to X the value 2. Under this interpretation, the translation just provided from tuple-based languages to token-based languages applies directly, which thus allows to lift the results obtained in Section 4 to tuple-based languages. In another interpretation, one may argue that one should find three occurrences of tuples which matches tpXq by possibly instantiating X to different values. Under this interpretation, the request askptpX : Intqp3qq not only succeeds but also askptpX : Intqp5qq since tp1q and tp2q both match tpXq. However, this interpretation is exactly what is captured by DBD-BachT language. In our example, askptpX : Intqp5qq could indeed be reformulated as askprtp1q, tp2q, tp3q, ¨¨¨sp5qq. Hence, under that second interpretation too, the results obtained in Section 4 can be lifted to tuple-based languages.

Implementation issues

The expressiveness study has shown that BachT is strictly less expressive than Dense BachT, which itself is strictly less expressive than VD-BachT, which is finally less expressive than MRT. One may thus wonder about the interest of all the languages, except the most expressive one. The aim of this section is to convince the reader that implementing the more expressive languages comes with a higher cost and thus that one better selects the language just expressive enough for its coding purposes.

To start with, let us first detail how the token space (or more generally the tuple space4 ) may be implemented for Bach. Since our first implementation (see [START_REF] De Bosschere | Multi-Prolog: Definition, Operational Semantics, and Implementation[END_REF]), processes have been implemented as threads and the tuple space has been implemented as a token-indexed list. Per list element (token), we keep track of the number of identical tokens (token counter), and of the input primitives that are suspended on this token. The token list is stored in shared memory. The list is directly updated by the communication primitives, as one may guess : the tell primitive adding tokens and the get primitive consuming them. In order to guarantee exclusive access, the individual list elements are protected by a lock, which means that operations on different tokens can execute in parallel. This has turned out to generate interesting speed-ups over the naive implementation which would lock the entire tuple space for each primitive execution. More precisely, the following algorithms are employed for the primitives.

Performing an nask primitive first checks whether the associated token is known to the tuple space (ie has already an element in the list of tokens). If not, the tuple space is locked, and a list element for the token is created. If the token counter equals zero, the nask-primitive succeeds. If not, it suspends, and is added to the list of suspended primitives, until the token counter reaches zero.

Asking a token t first checks whether at least one occurrence of t is present in the tuple space. If so, the primitive succeeds. Otherwise, the ask primitive is put in the associated list of waiting processes, until the token counter is positive.

Getting a token t proceeds similarly but decrements the token counter for t. If the token counter reaches zero, we check whether there are suspended naskptq primitives. If so, the process associated with the nask primitive is resumed and is removed from the list of waiting primitives.

Finally, telling a token t proceeds dually. The list of waiting processes is first inspected to discover an ask or get primitive waiting for t. In case an ask primitive is discovered, it is resumed and the search continues. In case a get primitive is discovered the token t is consumed by that primitive and the corresponding process is resumed. If no waiting get primitives are encountered, then the token counter for t is incremented.

As the careful reader will have noticed, lifting the Bach implementation to Dense Bach is quite easy. One basically just needs to count the number of occurrences of the tokens for the ask and get primitives and to upgrade the number of tokens for the tell primitives. The case of general tuples is slightly more complicated in that pattern matching needs to be done in addition but only on the elements of the list associated with the functor taken as a token. However, the key property remains : the tuple space need not be blocked globally, locks are only put on the list associated with the considered token.

Moving to VD-Bach is more subtle since several locks need to be taken and hence the above key property cannot be met. Consider for instance a multiget primitive which needs to consume tokens a, b and c. To evaluate it, one needs in principle to lock the lists associated with a, b and c. However, as other primitives may compete, for instance to get b, c and d, one actually needs to lock at once the three lists associated with a, b and c in order to prevent the system from deadlocks. In practice, an easy way to do so is to lock the whole tuple space. However, by using abstract interpretation techniques on a static code or by using declarations on the vectors employed and by employing the activator vectors of [START_REF] Jacquet | Blackboard Rules: from a Declarative Reading to its Application for Coordinating Context-aware Applications in Mobile Ad Hoc Networks[END_REF], one may slightly relax the global lock by adding locks for super sets of vectors, in the example above to a, b, c and d. This still allows for parallel computations, although to a lesser extend than for Dense Bach.

It is worth noting that the more the structure involves tokens the more constraining are the locks used. In particular, a similar technique can be used to implement MRT but, as one may expect, with a greater computation overhead.

As a conclusion, the more expressive the language is the more expensive is its implementation. Hence, there is obviously a trade-off to be made between the programming ease offered by the language expressiveness and the computation costs needed by its implementation.

Conclusion

This paper is written in the continuity of our previous research on the expressiveness of Linda-like languages. It has presented extensions of our Bach language aiming at handling multiplicities. In particular, as a novel piece of work, we have presented an extension of our Dense BachT language, that has promoted the interest of vectors of dense tokens. The new language, called Vectorized Dense BachT proposes to atomically perform multiple operations on dense tokens by introducing lists of dense tokens in the four classical primitives of our BachT language.

Our work thus builds upon our previous work [START_REF] Brogi | On the Expressiveness of Coordination Models[END_REF][START_REF] Brogi | On the Expressiveness of Coordination via Shared Dataspaces[END_REF][START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF][START_REF] Jacquet | On Density in Coordination Languages[END_REF][START_REF] Jacquet | On the Introduction of Density in Tuple-Space Coordination Languages[END_REF][START_REF] Linden | On the Expressiveness of Absolute-Time Coordination Languages[END_REF][START_REF] Linden | On the Expressiveness of Timed Coordination via Shared Dataspaces[END_REF][START_REF] Linden | On the Expressiveness of Relative-Timed Coordination Models[END_REF]. We have essentially followed the same lines and in particular have used De Boer and Palamidessi's notion of modular embedding to compare the families of sublanguages of Dense BachT and Vectorized Dense BachT. Accordingly, we have established a gain of expressivity, namely that Vectorized Dense BachT is strictly more expressive than Dense BachT and, consequently, in view of the results of [START_REF] Jacquet | On Density in Coordination Languages[END_REF], strictly more expressive than the BachT and Linda languages. However the structure of the hierarchies of the sublanguages of a family is kept, which shows that the very nature of the tell, ask, get and nask primitives is preserved. We have also compared Vectorized Dense BachT with a multiset rewriting language and showed that it is strictly less expressive. However, as shown in the paper, it is expressive enough to code interesting applications as well as Dense Bach with Distributed Density, a language we introduced in [START_REF] Darquennes | On Distributed Density in Tuplebased Coordination Languages[END_REF]. Moreover, the fact that Vectorized Dense BachT only provides atomic tell, ask, nask and get allows for more efficient implementations than MRT.

Our work has similarities but also differences with several work on the expressiveness of Linda-like languages. Compared to [START_REF] Zavattaro | On the incomparability of Gamma and Linda[END_REF] and [START_REF] Zavattaro | Towards a Hierarchy of Negative Test Operators for Generative Communication[END_REF], it is worth observing that a different comparison criteria is used to compare the expressiveness of languages. Indeed, in these pieces of work, the comparison is performed on (i) the compositionality of the encoding with respect to parallel composition, (ii) the preservation of divergence and deadlock, and (iii) a symmetry condition. Moreover, we have taken a more liberal view with respect to the preservation of termination marks in requiring these preservations on the store resulting from the execution from the empty store of the coded versions of the considered agents and not on the same store. In particular, these ending stores are not required to be of the form σ Y σ (where Y denotes multi-set union) if this is so for the stores resulting from the agents themselves.

In [START_REF] Bonsangue | Comparing coordination models based on shared distributed replicated data[END_REF], nine variants of the L B pask,nask,get,tellq language are studied. They are obtained by varying both the nature of the shared data space and its structure. Rephrased in the setting of [START_REF] De Boer | Embedding as a Tool for Language Comparison[END_REF], this amounts to considering different operational semantics. In contrast, in our work we fix an operational semantics and compare different languages on the basis of this semantics. In [START_REF] Busi | A Process Algebraic View of Linda Coordination Primitives[END_REF], a process algebraic treatment of a family of Linda-like concurrent languages is presented. Again, different semantics are considered whereas we have sticked to one semantics and have compared languages on this basis.

In [START_REF] Busi | On the Turing equivalence of Linda coordination primitives[END_REF], a study of the absolute expressive power of different variants of Lindalike languages has been made, whereas we study the relative expressive power of different variants of such languages (using modular embedding as a yard-stick and the ordered interpretation of tell).

It is worth observing that [START_REF] Bonsangue | Comparing coordination models based on shared distributed replicated data[END_REF][START_REF] Busi | On the Turing equivalence of Linda coordination primitives[END_REF][START_REF] Busi | A Process Algebraic View of Linda Coordination Primitives[END_REF][START_REF] Zavattaro | On the incomparability of Gamma and Linda[END_REF][START_REF] Zavattaro | Towards a Hierarchy of Negative Test Operators for Generative Communication[END_REF] do not deal with a notion of density attached to tuples. In contrast, [START_REF] Bravetti | Quantitative Information in the Tuple Space Coordination Model[END_REF] and [START_REF] Bravetti | Probabilistic and Prioritized Data Retrieval in the Linda Coordination Model[END_REF] decorate tuples with an extra field in order to investigate how probabilities and priorities can be introduced in the Linda coordination model. Different expressiveness results are established in [START_REF] Bravetti | Quantitative Information in the Tuple Space Coordination Model[END_REF] but on an absolute level with respect to Turing expressiveness and the possibility to encode the Leader Election Problem. Our work contrasts in several aspects. First, we have established relative expressiveness results by comparing the sublanguages of two families. Moreover, some of these sublanguages incorporate the nask primitives, which, strictly increases the expressiveness. Finally, the introduction of density resembles but is not identical to the association of weights to tuples. Indeed, in contrast to [START_REF] Bravetti | Quantitative Information in the Tuple Space Coordination Model[END_REF][START_REF] Bravetti | Probabilistic and Prioritized Data Retrieval in the Linda Coordination Model[END_REF] we do not modify the tuples on the store and do not modify the matching function so as to retrieve the tuple with the highest weight. In contrast, we modify the tuple primitives so as to be able to atomically put several occurrences of a tuple on the store and check for the presence or absence of a number of occurrences. As can be appreciated by the reader through the comparison of BachT, Dense BachT and Vectorized Dense BachT, this facility of handling atomically several occurrences produces a real increase of expressiveness. One may however naturally think of encoding the number of occurrences of a tuple as an additional weight-like parameter. It is nevertheless not clear how our primitives tackling at once several occurrences can be rephrased in Linda-like primitives and how the induced encoding would still fulfills the requirements of modularity. This will be the subject for future research.

In [START_REF] Viroli | Biochemical Tuple Spaces for Self-organising Coordination[END_REF], Viroli and Casadei propose a stochastic extension of the Linda framework, with a notion of tuple concentration, similar to the weight of [START_REF] Bravetti | Quantitative Information in the Tuple Space Coordination Model[END_REF] and [START_REF] Bravetti | Probabilistic and Prioritized Data Retrieval in the Linda Coordination Model[END_REF] and our notion of density. The syntax of this tuple space is modeled by means of a calculus, with an operational semantics given as an hybrid CTMC/DTMC model. This operational semantics describes the behavior of tell, ask and get like primitives but does not consider a nask like primitive. Moreover, no expres-siveness results are established and there is no counterpart for non-determinism arising from the distribution of density on tokens.

These three last pieces of work tackle probabilistic extensions of Linda-like languages. As a further and natural step in our research, we aim at studying how our notions of multiplicity can be the basis of such probabilistic extensions.

Definition 2 .

 2 Define the set T b of the token-based primitives as the set of primitives T b generated by the following grammar: T b ::" tellptq | askptq | getptq | naskptq where t represents a token. Similarly, define the set of dense token-based primitives T db as the set of primitives T db generated by the following grammar: T db ::" tellptpmqq | askptpmqq | getptpmqq | naskptpmqq where t represents a token and m a positive natural number.

Fig. 1 .

 1 Fig. 1. Transition rules for token-based primitives (BachT)

Fig. 2 .

 2 Fig. 2. Transition rules for dense token-based primitives (Dense BachT)

pTvq m1 ,Fig. 3 .

 m13 Fig. 3. Transition rules for vectorized dense token-based primitives (VD-BachT)

Fig. 4 .

 4 Fig. 4. Transition rule for the weak nask

Fig. 5 .Definition 5 .

 55 Fig. 5. Transition rules for multi-set rewriting-based primitives (MRT)

Fig. 6 .

 6 Fig. 6. Transition rules for the operators

Fig. 7 .

 7 Fig. 7. Transition rules for list of token-based primitives (Dense BachT with distributed Density)

Fig. 8 .

 8 Fig. 8. Basic embedding.

Fig. 10 .

 10 Fig. 10. Embedding hierarchy of BachT and Dense BachT

Proposition 2 L

 2 MR ptellq and L V B ptellq are equivalent. Proof. We have L V B ptellq ď L MR ptellq by Proposition 1. Furthermore, L MR ptellq ď L V B ptellq is established by coding any tell primitive of L MR ptellq as the composition of their dense versions : Cptu, t`t 1 , ¨¨¨, `t1 loooooomoooooon m1 times , ¨¨¨, `tk , ¨¨¨, `tk loooooomoooooon m k times

Proposition 7 L

 7 V B pask,nask,tellq ≀ L MR pnask,tellq Proof. (i) We have that L V B pask,nask,tellq ę L MR pnask,tellq. Otherwise, by embedding by transitivity, L V B pask,tellq ď L MR pnask,tellq, which has been proved impossible in Proposition 6.

  Definition 4. Define the set of vectorized dense token-based primitives T vb as the set of primitives T vb generated by the following grammar: ¨¨¨, tnpmnqq | σq y ÝÑ x E | σ y

		pWvq	m1, ¨¨¨, mn P N0, tt1pp1q, ¨¨¨, tnppnqu Ę σ x wnaskpt1pm1q,
		T vb ::" tellp ÝÝÑ tpmqq | askp ÝÝÑ tpmqq | getp ÝÝÑ tpmqq | naskp ÝÝÑ tpmqq
	where	ÝÝÑ tpmq represents a vector of dense tokens.

  LV B pnask, get, tellq LV B pask, nask, get, tellq

		LDBptellq
		LV B ptellq
		LDBpnask, tellq	LDBpask, tellq
	LV B pnask, tellq	LDBpask, nask, tellq	LDBpget, tellq LDBpask, get, tellq	LV B pask, tellq
	LV B pask, nask, tellq	LDBpnask, get, tellq LDBpask, nask, get, tellq	LV B pget, tellq LV B pask, get, tellq

Fig. 11. Embedding hierarchy of Dense BachT and Vectorized Dense BachT languages.

  uy is a valid computation prefix of CpAB || BAq. It should deadlock afterwards since OpAB || BAq " pH, δ ´q. However D is also a valid computation prefix of CppAB || BAq `ptu, t`auqq. Hence, CppAB || BAq `ptu, t`auqq admits a failing computation which contradicts the fact that OppAB || BAq `ptu, t`auqq " ptau, δ `q.

  We finally prove that L V B pask,nask,get,tellq is strictly less expressive than L MR pask,nask,get,tellq.Proposition 19 L V B pask,nask,get,tellq ă L MR pask,nask,get,tellq Proof. On the one hand, L V B pask,nask,get,tellq ď L MR pask,nask,get,tellq is immediate by Proposition 1. On the other hand, L MR pask,nask,get,tellq ę L V B pask,nask,get,tellq is established by contradiction. Indeed, assuming that L MR pask,nask,get,tellq ď L V B pask,nask,get,tellq, as L V B pask,nask,get,tellq " L V B pnask,get,tellq, one would have L MR pnask, tellq ď L MR pask,nask,get,tellq ď L V B pask,nask,get,tellq ď L V B pnask,get,tellq which has been proved impossible in Proposition 12.

					'	LMR(tell)
	LMR(nask,tell)	'		'	LMR(ask,tell)
	LMR(ask,nask,tell)	'			'	LMR(get,tell)
			'	LMR(ask,nask,get,tell)
				LV B (tell)	'
			'	LV B (nask,tell)	'	LV B (ask,tell)
	LV B (ask,nask,tell)	'		LV B (get,tell)	'
			'	LV B (ask,nask,get,tell)
				LDB(tell)	'
			'	LDB(nask,tell)	'	LDB(ask,tell)
	LDB(ask,nask,tell)	'		LDB(get,tell)	'
			'	LDB(ask,nask,get,tell)
				LB(tell)	'
			'	LB(nask,tell)	'	LB(ask,tell)
	LB(ask,nask,tell)	'		LB(get,tell)	'
			'	LB(ask,nask,get,tell)
	Fig. 12. Three-dimensional representation of the expressiveness relations between the
	different languages.
	D. Checking for presence and/or absence when adding and/or
	retrieving tokens

In Linda, variables are also allowed in tell primitives to denote unknown attributes. However, as argued in[START_REF] Brogi | On Modeling Coordination via Asynchronous Communication and Enhanced Matching[END_REF], we believe that it is better to use ψ-terms in this case, which allows to keep the idea of structured information without the need for writing unknown arguments.

In Bach, following[START_REF] Brogi | On Modeling Coordination via Asynchronous Communication and Enhanced Matching[END_REF], tuples are actually represented in the form of a functor name followed by a series of pairs, each consisting of an attribute associated with a value. Without entering into details, the functor names play the role of tokens and, in that manner, the implementation sketched in this section can be lifted from the tokens considered in this paper to more general tuples.

Acknowledgment

We thank the anonymous reviewers for their comments and suggestions. We also thank A. Brogi and E. de Vink for helpful discussions on the expressiveness of coordination languages.