D Cristescu

Hirschkoff

Ioana Cristescu

Daniel Hirschkoff

Termination in a π-calculus with Subtyping

We present a type system to guarantee termination of π-calculus processes that exploits input/output capabilities and subtyping, as originally introduced by Pierce and Sangiorgi, in order to analyse the usage of channels.

We show that our system improves over previously existing proposals by accepting more processes as terminating. This increased expressiveness allows us to capture sensible programming idioms. We demonstrate how our system can be extended to handle the encoding of the simply typed λ -calculus, and discuss questions related to type inference.

Introduction

Although many concurrent systems, such as servers, are supposed to run forever, termination is an important property in a concurrent setting. For instance, one would like a request to a server to be eventually answered; similarly, the access to a shared resource should be eventually granted. Termination can be useful to guarantee in turn lock-freedom properties [START_REF] Kobayashi | A hybrid type system for lock-freedom of mobile processes[END_REF].

In this work, we study termination in the setting of the π-calculus: concurrent systems are specified as π-calculus processes, and we would like to avoid situations in which a process can perform an infinite sequence of internal communication steps. Despite its conciseness, the π-calculus can express complex behaviours, such as reconfiguration of communication topology, and dynamic creation of channels and threads. Guaranteeing termination is thus a nontrivial task.

More specifically, we are interested in methods that provide termination guarantees statically. There exist several type-based approaches to guarantee termination in the π-calculus [START_REF] Deng | Ensuring termination by typability[END_REF][START_REF] Yoshida | Strong Normalisation in the Pi-Calculus[END_REF][START_REF] Sangiorgi | Termination of Processes[END_REF][START_REF] Demangeon | Mobile Processes and Termination[END_REF][START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF]. In these works, any typable process is guaranteed to be reactive, in the sense that it cannot enter an infinite sequence of internal communications: it eventually terminates computation, or ends up in a state where an interaction with the environment is required.

The type systems in the works mentioned above have different expressive powers. Analysing the expressiveness of a type system for termination amounts to studying the class of processes that are recognised as terminating. A type system for termination typically rules out some terminating terms, because it is not able to recognise them as such (by essence, an effective type system for termination defines an approximation of this undecidable property). When improving expressiveness, one is interested in making the type system more flexible: more processes should be deemed as terminating. An important point in doing so is also to make sure that (at least some of) the 'extra processes' make sense from the point of view of programming.

Type systems for termination in the π-calculus. Existing type systems for termination in the πcalculus build on simple types [START_REF] Sangiorgi | The π-calculus: a Theory of Mobile Processes[END_REF], whereby the type of a channel describes what kind of values it can carry. Two approaches, that we shall call 'level-based' and 'semantics-based', have been studied to guarantee termination of processes. We discuss below the first kind of methods, and return to semanticsbased approaches towards the end of this section. Level-based methods for the termination of processes originate in [START_REF] Deng | Ensuring termination by typability[END_REF], and have been further analysed and developed in [START_REF] Demangeon | Mobile Processes and Termination[END_REF]. They exploit a stratification of names, obtained by associating a level (given by a natural number) to each name. Levels are used to insure that at every reduction step of a given process, some well-founded measure defined on processes decreases.

Let us illustrate the level-based approach on some examples. In this paper, we work in the asynchronous π-calculus, and replication can occur only on input prefixes. As in previous work, adding features like synchrony or the sum operator to our setting does not bring any difficulty.

According to level-based type systems, the process !a(x).b x is well-typed provided lvl(a), the level of a, is strictly greater than lvl(b). Intuitively, this process trades messages on a (that 'cost' lvl(a)) for messages on b (that cost less). Similarly, !a(x).(b x | b x ) is also well-typed, because none of the two messages emitted on b will be liable to trigger messages on a ad infinitum. More generally, for a process of the form !a(x).P to be typable, we must check that all messages occurring in P are transmitted on channels whose level is strictly smaller than lvl(a) (more accurately, we only take into account those outputs that do not occur under a replication in P -see Section 2).

This approach rules out a process like !a(x).b x | !b(y).a y (which generates the unsatisfiable constraint lvl(a) > lvl(b) > lvl(a)), as well as the other obviously 'dangerous' term !a(x).a x -note that neither of these processes is diverging, but they lead to infinite computations as soon as they are put in parallel with a message on a.

The limitations of simple types. The starting point of this work is the observation that since existing level-based systems rely on simple types, they rule out processes that are harmless from the point of view of termination, essentially because in simple types, all names transmitted on a given channel should have the same type, and hence, in our setting, the same level as well.

If we try for instance to type the process P 0 de f = !a(x).x t , the constraint is lvl(a) > lvl(x), in other words, the level of the names transmitted on a must be smaller than a's level. It should therefore be licit to put P 0 in parallel with a p | a q , provided lvl(p) < lvl(a) and lvl(q) < lvl(a). Existing type systems enforce that p and q have the same type for this process to be typable: as soon as two names are sent on the same channel (here, a), their types are unified. This means that if for some reason (for instance, if the subterm !p(z).q z occurs in parallel) we must have lvl(p) > lvl(q), the resulting process is rejected, although it is terminating.

We would like to provide more flexibility in the handling of the level of names, by relaxing the constraint that p and q from the example above should have the same type. To do this while preserving soundness of the type system, it is necessary to take into account the way names are used in the continuation of a replicated input. In process P 0 above, x is used in output in the continuation, which allows one to send on a any name (of the appropriate simple type) of level strictly smaller than lvl(a). If, on the other hand, we consider process P 1 de f = !b(y).!y(z).c z , then typability of the subterm !y(z).c z imposes lvl(y) > lvl(c), which means that any name of level strictly greater than lvl(c) can be sent on b. In this case, P 1 uses the name y that is received along b in input. We can remark that divergent behaviours would arise if we allowed the reception of names having a bigger (resp. smaller) level in P 0 (resp. P 1 ).

Contributions of this work. These observations lead us to introduce a new type system for termination of mobile processes based on Pierce and Sangiorgi's system for input/output types (i/o-types) [START_REF] Pierce | Typing and Subtyping for Mobile Processes[END_REF]. I/otypes are based on the notion of capability associated to a channel name, which makes it possible to grant only the possibility of emitting (the output capability) or receiving (the input capability) on a given channel. A subtyping relation is introduced to express the fact that a channel for which both capabilities are available can be coerced to a channel where only one is used. Intuitively, being able to have a more precise description of how a name will be used can help in asserting termination of a process: in P 0 , only the output capability on x is used, which makes it possible to send a name of smaller level on a; in P 1 , symmetrically, y can have a bigger level than expected, as only the input capability on y is transmitted.

The overall setting of this work is presented in Section 2, together with the definition of our type system. This system is strictly more expressive than previously existing level-based systems. We show in particular that our approach yields a form of 'level polymorphism', which can be interesting in terms of programming, by making it possible to send several requests to a given server (represented as a process of the form ! f (x).P, which corresponds to the typical idiom for functions or servers in the π-calculus) with arguments that must have different levels, because of existing dependencies between them.

In order to study more precisely the possibility to handle terminating functions (or servers) in our setting, we analyse an encoding of the λ -calculus in the π-calculus. We have presented in [START_REF] Demangeon | Mobile Processes and Termination[END_REF] a counterexample showing that existing level-based approaches are not able to recognise as terminating the image of the simply-typed λ -calculus (STλ ) in the π-calculus (all processes computed using such an encoding terminate [START_REF] Sangiorgi | The π-calculus: a Theory of Mobile Processes[END_REF]). We show that this counterexample is typable in our system, but we exhibit a new counterexample, which is not. This shows that despite the increased expressiveness, level-based methods for the termination of π-calculus processes fail to capture terminating sequential computation as expressed in STλ .

To accommodate functional computation, we exploit the work presented in [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], where an impure π-calculus is studied. Impure means here that one distinguishes between two kinds of names. On one hand, functional names are subject to a certain discipline in their usage, which intuitively arises from the way names are used in the encoding of STλ in the π-calculus. On the other hand, imperative names do not obey such conditions, and are called so because they may lead to forms of stateful computation (for instance, an input on a certain name is available at some point, but not later, or it is always available, but leads to different computations at different points in the execution).

In [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], termination is guaranteed in an impure π-calculus by using a level-based approach for imperative names, while functional names are dealt with separately, using a semantics-based approach [START_REF] Yoshida | Strong Normalisation in the Pi-Calculus[END_REF][START_REF] Sangiorgi | Termination of Processes[END_REF]. We show that that type system, which combines both approaches for termination in the π-calculus, can be revisited in our setting. We also demonstrate that the resulting system improves in terms of expressiveness over [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], from several points of view.

Several technical aspects in the definition of our type systems are new with respect to previous works. First of all, while the works we rely on for termination adopt a presentation à la Church, where every name has a given type a priori, we define our systems à la Curry, in order to follow the approach for i/o-types in [START_REF] Pierce | Typing and Subtyping for Mobile Processes[END_REF]. As we discuss below, this has some consequences on the soundness proof of our systems. Another difference is in the presentation of the impure calculus: [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF] uses a specific syntactical construction, called def, and akin to a let .. in construct, to handle functional names. By a refinement of i/o-types, we are able instead to enforce the discipline of functional names without resorting to a particular syntactical construct, which allows us to keep a uniform syntax.

We finally discuss type inference, by focusing on the case of the localised π-calculus (Lπ). Lπ corresponds to a certain restriction on i/o-types. This restriction is commonly adopted in implementations of the π-calculus. We describe a sound and complete type inference procedure for our level-based system in Lπ. We also provide some remarks about inference for i/o-types in the general case.

Paper outline. Section 2 presents our type system, and shows that it guarantees termination. We study its expressiveness in Section 3. Section 4 discusses type inference, and we give concluding remarks in Section 5. For lack of space, several proofs are omitted from this version of the paper.

A Type System for Termination with Subtyping

Definition of the Type System

Processes and types. We work with an infinite set of names, ranged over using a, b, c, . . . , x, y, . . . . Processes, ranged over using P, Q, R, . . . , are defined by the following grammar ( is a constant, and we use v for values):

P ::= 0 0 0 P 1 |P 2 a v (ν ν νa) P a(x).P !a(x).P v ::= a .
The constructs of restriction and (possibly replicated) input are binding, and give rise to the usual notion of α-conversion. We write fn(P) for the set of free names of process P, and P[b/x] stands for the process obtained by applying the capture-avoiding substitution of x with b in P.

We moreover implicitly assume, in the remainder of the paper, that all the processes we manipulate are written in such a way that all bound names are pairwise distinct and are different from the free names. This may in particular involve some implicit renaming of processes when a reduction is performed.

The grammar of types is given by:

T ::= k T i k T o k T U ,
where k is a natural number that we call a level, and U stands for the unit type having as only value.

A name having type k T has level k, and can be used to send or receive values of type T , while type i k T (resp. o k T ) corresponds to having only the input (resp. output) capability. Figure 1 introduces the subtyping and typing relations. We note ≤ both for the subtyping relation and for the inequality between levels, as no ambiguity is possible. We can remark that the input (resp. output) capability is covariant (resp. contravariant) w.r.t. ≤, but that the opposite holds for levels: input requires the supertype to have a smaller level.

Γ ranges over typing environments, which are partial maps from names to types -we write Γ(a) = T if Γ maps a to T . dom(Γ), the domain of Γ, is the set of names for which Γ is defined, and Γ, a : T stands for the typing environment obtained by extending Γ with the mapping from a to T , this operation being defined only when a / ∈ dom(Γ). The typing judgement for processes is of the form Γ P : w, where w is a natural number called the weight of P. The weight corresponds to an upper bound on the maximum level of a channel that is used in output in P, without this output occurring under a replication. This can be read from the typing rule for output messages (notice that in the first premise, we require the output capability on a, which may involve the use of subtyping) and for parallel composition. As can be seen by the corresponding rules, non replicated input prefix and restriction do not change the weight of a process. The weight is controlled in the rule for replicated inputs, where we require that the level of the name used in input is strictly bigger than the weight of the continuation process. We can also observe that working in a synchronous calculus would involve a minor change: typing a synchronous output a v .P would be done essentially like typing a v | P in our setting (with no major modification in the correctness proof for our type system).

As an abbreviation, we shall omit the content of messages in prefixes, and write a and a for a(x) and a respectively, when a's type indicates that a is used to transmit values of type U. Example 1 The process !a(x).x t | a p | a q | !p(z).q z from Section 1 can be typed in our type system: we can set a : 3 o 2 T, p : 2 T, q : o 1 T . Subtyping on levels is at work in order to typecheck the subterm a q . We provide a more complex term, which can be typed using similar ideas, in Example 15 below. Γ (ν ν νa) P : w

Γ P 1 : w 1 Γ P 2 : w 2 Γ P 1 |P 2 : max(w 1 , w 2 )
Figure 1: Typing and Subtyping Rules

a(x).P | a v -→ P[v/x] !a(x).P | a v -→ !a(x).P | P[v/x] P -→ P P|Q -→ P |Q P -→ P (ν ν νa) P -→ (ν ν νa) P Q ≡ P P -→ P P ≡ Q Q -→ Q Figure 2: Reduction of Processes
Reduction and termination. The definition of the operational semantics relies on a relation of structural congruence, noted ≡, which is the smallest equivalence relation that is a congruence, contains α-conversion, and satisfies the following axioms:

P|(Q|R) ≡ (P|Q)|R P|Q ≡ Q|P P|0 0 0 ≡ P (ν ν νa) 0 0 0 ≡ 0 0 0 (ν ν νa)(ν ν νb) P ≡ (ν ν νb)(ν ν νa) P (ν ν νa) (P|Q) ≡ P | (ν ν νa) Q if a / ∈ fn(P)
Note in particular that there is no structural congruence law for replication. Reduction, written -→, is defined by the rules of Figure 2.

Definition 2 (Termination) A process P diverges if there exists an infinite sequence of processes (P i ) i≥0 such that P = P 0 and for any i, P i -→ P i+1 . P terminates (or P is terminating) if P does not diverge.

Properties of the Type System

We first state some (mostly standard) technical properties satisfied by our system. Proof (sketch). This is a consequence of Lemma 4, as we replace x by a name of smaller type.

Theorem 7 (Subject reduction) If Γ P : w and P -→ P , then Γ P : w for some w ≤ w.

Proof (sketch). By induction over the derivation of P -→ P . The most interesting case corresponds to the case where

P =!a(x).P 1 | a v -→ P =!a(x).P 1 | P 1 [v/x]
. By typability of P, we have Γ !a(x).P 1 : 0.

Let T a = Γ(a). Typability of P gives Γ, x : T P 1 : w 1 for some T and w 1 such that T a ≤ i k T and w 1 < k ≤ lvl(a). Typability of a v gives T a ≤ o k U for some k ≥ lvl(a), with w = k and Γ v : U. The two constraints on T a entail T ≤ U, and hence, by Lemma 6,

Γ P 1 [v/x] : w 2 for some w 2 ≤ w 1 ≤ lvl(a) ≤ k .
We then conclude Γ P : w 2 .

Termination. Soundness of our type system, that is, that every typable process terminates, is proved by defining a measure on processes that decreases at each reduction step. A typing judgement Γ P : w yields the weight w of process P, but this notion is not sufficient (for instance, a | a | a -→ a, and the weight is preserved). We instead adapt the approach of [START_REF] Demangeon | Terminaison des systèmes concurrents[END_REF], and define the measure as a multiset of natural numbers. This is done by induction over the derivation of a typing judgement for the process. We will use D to range over typing derivations, and write D : Γ P : w to mean that D is a derivation of Γ P : w.

To deduce termination, we rely on the multiset extension of the well-founded order on natural numbers, that we write

> mul . M 2 > mul M 1 holds if M 1 = N N 1 , M 2 = N N 2 ,
N being the maximal such multiset ( is multiset union), and for all e 1 ∈ N 1 there is e 2 ∈ N 2 such that e 1 < e 2 . The relation > mul is well-founded. We write

M 1 ≥ mul M 2 if M 1 > mul M 2 or M 1 = M 2 .
Definition 8 Suppose D : Γ P : w. We define a multiset of natural numbers, noted M (D), by induction over D as follows:

If D : Γ 0 0 0 then M (D) = / 0 If D : Γ a b : k then M (D) = {lvl(a)} If D : Γ !a(x).P : 0 then M (D) = / 0 If D : Γ a(x).P : w, then M (D) = M (D 1 ), where D 1 : Γ, x : T P : w If D : Γ (ν ν νa) P : w, then M (D) = M (D 1 )
, where D 1 : Γ, a : T P : w

If D : Γ P 1 |P 2 : max(w 1 , w 2 ), then M (D) = M (D 1 ) M (D 2 ), where D i : Γ P i , i = 1, 2
Given Γ and P, we define M Γ (P), the measure of P with respect to Γ, as follows:

M Γ (P) = min(M (D), D : Γ P : w for some w) .

Note that in the case of output in the above definition, we refer to lvl(a), which is the level of a according to Γ (that is, without using subtyping). We have that if Γ P : w, then ∀k ∈ M Γ (P), k ≤ w.

Lemma 9 Suppose Γ P : w, Γ(x) = T , Γ(v) = T and T ≤ T . Then M Γ (P) ≥ mul M Γ (P[v/x]).
Proof Follows from Lemma 6, and by definition of M Γ (•).

Lemma 10 If Γ P : w and P ≡ Q, then Γ Q : w for some w and M Γ (P) = M Γ (Q).

We are now able to derive the essential property of M Γ (•):

Lemma 11 If Γ P : w and P -→ P , then M Γ (P) > mul M Γ (P ).

Theorem 12 (Soundness) If Γ P : w, then P terminates.

Proof Suppose that P diverges, i.e., there is an infinite sequence(P i ) i∈N , where P i -→ P i+1 , P = P 0 . According to Theorem 7 every P i is typable. Using Lemma 11 we have M Γ (P i ) > mul M Γ (P i+1 ) for all i, which yields a contradiction.

Remark 13 (à la Curry vs à la Church) Our system is presented à la Curry. Existing systems for termination [START_REF] Deng | Ensuring termination by typability[END_REF][START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF] are à la Church, while the usual presentations of i/o-types [START_REF] Pierce | Typing and Subtyping for Mobile Processes[END_REF] are à la Curry. The latter style of presentation is better suited to address type inference (see Section 4). This has however some technical consequences in our proofs. Most importantly, the measure on processes (Definition 8) would be simpler when working à la Church, because we could avoid to consider all possible derivations of a given judgement. We are not aware of Church-style presentations of i/o-types.

Expressiveness of our Type System

For the purpose of the discussions in this section, we work in a polyadic calculus. The extension of our type system to handle polyadicity is rather standard, and brings no particular difficulty.

A More Flexible Handling of Levels

Our system is strictly more expressive than the original one by Deng and Sangiorgi [START_REF] Deng | Ensuring termination by typability[END_REF], as expressed by the two following observations (Lemma 14 and Example 15): Lemma 14 Any process typable according to the first type system of [START_REF] Deng | Ensuring termination by typability[END_REF] is typable in our system.

Proof The presentation of [START_REF] Deng | Ensuring termination by typability[END_REF] differs slightly from ours. The first system presented in that paper can be recast in our setting by working with the # capability only (thus disallowing subtyping), and requiring type k T for a in the first premise of the rules for output, finite input and replicated input. We write Γ D P : w for the resulting judgement. We establish that Γ D P : w implies Γ P : w by induction over the derivation of Γ D P : w. We now present an example showing that the flexibility brought by subtyping can be useful to ease programming. We view replicated processes as servers, or functions. Our example shows that it is possible in our system to invoke a server by passing names having different levels, provided some form of coherence (as expressed by the subtyping relation) is guaranteed. This form of "polymorphism on levels" is not available in previous type systems for termination in the π-calculus.

Example 15 (Level-polymorphism) Consider the following definitions (in addition to polyadicity, we accommodate the first-order type of natural numbers, with corresponding primitive operations):

F 1 = ! f 1 (n, r).r n * n F 2 = ! f 2 (m, r).(ν ν νs) f 1 m + 1, s | s(x).r x + 1 Q = !g(p,
x, r).(ν ν νs) p x, s | s(y).p y, r F 1 is a server, running at f 1 , that returns the square of a integer on a continuation channel r (which is its second argument). F 2 is a server that computes similarly (m + 1) 2 + 1, by making a call to F 1 to compute (m + 1) 2 . Both F 1 and F 2 can be viewed as implementations of functions of type int -> int.

Q is a "higher-order server": its first argument p is the address of a server acting as a function of type int -> int, and Q returns the result of calling twice the function located at p on its argument (process Q thus somehow acts like Church numeral 2).

Let us now examine how we can typecheck the process

F 1 | F 2 | Q | g f 1 , 4,t 1 | g f 2 , 5,t 2 .
F 2 contains a call to f 1 under a replicated input on f 2 , which forces lvl( f 2 ) > lvl( f 1 ). In the type systems of [START_REF] Deng | Ensuring termination by typability[END_REF], this prevents us from typing the processes above, since f 1 and f 2 should have the same type (and hence in particular the same level), both being used as argument in the outputs on g. We can type this process in our setting, thanks to subtyping, for instance by assigning the following types: g :

o k g (o k 2 T,U,V ), f 2 : k 2 T, f 1 : k 1 T , with k 1 < k 2 .
It can be shown that this example cannot be typed using any of the systems of [START_REF] Deng | Ensuring termination by typability[END_REF]. It can however be phrased (and hence recognised as terminating) in the "purely functional π-calculus" of [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], that is, using a semantics-based approach -see also Section 3.3. It should however not be difficult to present a variation on it that forces one to rely on levels-based type systems.

Encoding the Simply-Typed λ -calculus

We now push further the investigation of the ability to analyse terminating functional behaviour in the π-calculus using our type system, and study an encoding of the λ -calculus in the π-calculus.

We focus on the following parallel call-by-value encoding, but we believe that the analogue of the results we present here also holds for other encodings. A λ -term M is encoded as [[M]] p , where p is a name which acts as a parameter in the encoding. The encoding is defined as follows:

[[λ x.M]] p de f = (ν ν νy) (!y(x, q).[[M]] q | p y ) [[x]] p de f = p x [[M N]] p de f = (ν ν νq, r) [[M]] q | [[N]] r | q( f ).r(z). f z, p
We can make the following remarks:

• A simply-typed λ -term is encoded into a simply-typed process (see [START_REF] Sangiorgi | The π-calculus: a Theory of Mobile Processes[END_REF]). Typability for termination comes into play in the translation of λ -abstractions.

• The target of this encoding is Lπ, the localised π-calculus in which only the output capability is transmitted (see also Section 4.1).

[3] provides a counterexample to typability of this encoding for the first type system of [START_REF] Deng | Ensuring termination by typability[END_REF] (the proof of this result also entails that typability according to the other, more expressive, type systems due to Deng and Sangiorgi also fails to hold). Let us analyse this example:

Example 16 (From [START_REF] Demangeon | Mobile Processes and Termination[END_REF]) The λ -term M 1 de f = f (λ x.( f u (u v)) can be typed in the simply typed λcalculus, in a typing context containing the hypotheses f :

(σ -→ τ) -→ τ -→ τ, v : σ , u : σ -→ τ.

Termination in a π-calculus with Subtyping

Computing [[M 1 ]] p yields the process:

(ν ν νq, r) (ν ν νy) r y | !y(x, q ).(ν ν νq 1 , r 1 , q 2 , r 2 , q 3 , r 3 ) q 2 f | r 2 u | q 2 ( f 2 ).r 2 (z 2 ). f 2 z 2 , q 1 [[ f u]] q 1 | q 3 u | r 3 v | q 3 ( f 3 ).r 3 (z 3 ). f 3 z 3 , r 1 [[u v]] r 1 | q 1 ( f 1 ).r 1 (z 1 ). f 1 z 1 , q      [[λ x. ( f u (u v))]] r | q f | q( f ).r(z). f z, p
If we try and type this term using the first type system of [START_REF] Deng | Ensuring termination by typability[END_REF], we can reason as follows: 1. By looking at the line corresponding to [[ f u]] q 1 , we deduce that the types of f and f 2 are unified, and similarly for z 2 and u.

Similarly, the next line ([[u v]

] r 1 ) implies that the types of f 3 and u are unified.

3. The last line above entails that the types assigned to f and f must be unified, and the same for the types of z and y (because of the output r y ). If we write k T 1 , T 2 for the type (simple) assigned to f , we have by remark 1 that u has type T 1 , and the same holds for y by remark 3. In order to typecheck the replicated term, we must have lvl(y) > lvl( f 3 ) = lvl(u) by remark 2, which is impossible since y and u have the same type.

While [[M 1 ]] p cannot be typed using the approach of [START_REF] Deng | Ensuring termination by typability[END_REF], it can be using the system of Section 2. Indeed, in that setting y and u need not have the same levels, so that we can satisfy the constraint lvl(y) > lvl(u). The last line above generates an output f y, p , which can be typed directly, without use of subtyping. To typecheck the output f u, q 1 , we "promote" the level of u to the level of y thanks to subtyping, which is possible because only the output capability on u is transmitted along f .

It however appears that our system is not able to typecheck the image of STλ , as the following (new) counterexample shows: Example 17 We first look at the following rather simple π-calculus process:

(ν ν νu) !u(x).x | (ν ν νv) (!v.u t | u v ) .
This process is not typable in our type system, although it terminates. Indeed, we can assign a type of the form k o n U to u, and m U to v. Type-checking the subterm !v.u t imposes k < m, and type-checking !u(x).x imposes k > n. Finally, type-checking u v gives m ≤ n, which leads to an inconsistency.

We can somehow 'expand' this process into the encoding of a λ -term: consider indeed

M 2 de f = λ u. ((λ v.(u v)) (λ y.(u t))) (λ x. (x a)) .
We do not present the (rather complex) process corresponding to [[M 2 ]] p . We instead remark that there is a sequence of reductions starting from [[M 2 ]] p and leading to !y 1 (u, q 1 ). !y 3 (v, q 4 ).u v, q 4 | !y 5 (y, q 5 ).u t, q 5 | y 3 y 5 , q 1 | !y 2 (x, q 2 ).x a, q 2 | y 1 y 2 , p .

These first reduction steps correspond to 'administrative reductions' (which have no counterpart in the original λ -calculus term). We can now perform some communications that correspond to β -reductions, and obtain a process which contains a subterm of the form u v, p | !v(y, q 5 ).u t, q 5 | !u(x, q 2 ).x a, q 2 . Some channel names appear in boldface in order to stress the similarity with the process seen above: for the same reasons, this term cannot be typed. By subject reduction (Theorem 7), a typable term can only reduce to a typable term. This allows us to conclude that [[M 2 ]] p is not typable in our system.

Γ, x : T • -P : w k ≥ w Γ • f : o k T ! f (x).P : 0 Γ, f : o k T a : o n U Γ, f : o k T v : U Γ • f : o k T a v : n Γ c : i n T Γ, x : T, f : o k U • -P : w n > w Γ • f : o k U c(x).P : 0 Γ c : i n T Γ, x : T, f : o k U • -P : w n > w Γ • f : o k U !c(x).P : 0 Γ • f : o k T P 1 Γ • f : o k T P 2 Γ • f : o k T P 1 |P 2 Γ, g : o k T • f : o n U P : w Γ • g : o k T (ν ν ν f ) P : w Γ, c : n T • f : o k U P : w Γ • f : o k U (ν ν νc) P : w

Subtyping and Functional Names

In order to handle functional computation as expressed by STλ , we extend the system of Section 2 along the lines of [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF]. The idea is to classify names into functional and imperative names. Intuitively, functional names arise through the encoding of STλ . For termination, these are dealt with using an appropriate method -the 'semantics-based' approaches discussed in Section 1, and introduced in [START_REF] Yoshida | Strong Normalisation in the Pi-Calculus[END_REF][START_REF] Sangiorgi | Termination of Processes[END_REF]. For imperative names, we resort to (an adaptation of) the rules of Section 2.

Our type system is à la Curry, and the kind of a name, functional or imperative, is fixed along the construction of a typing derivation. Typing environments are of the form Γ • f : o k T -the intuition is that we isolate a particular name, f . f is the name which can be used to build replicated inputs where f is treated as a functional name. The typing rules are given on Figure 3. There are two rules to typecheck a restricted process, according to whether we want to treat the restricted name as functional (in which case the isolated name changes) or imperative (in which case the typing hypothesis is added to the Γ part of the typing environment).

The typing rules of Figure 3 rely on i/o-capabilities and the isolated name to enforce the usage of functional names as expressed in [START_REF] Sangiorgi | Termination of Processes[END_REF]. In [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], a specific syntactical construct is instead used: we manipulate processes of the form def f = (x)P 1 in P 2 (that can be read as (ν ν ν f ) (! f (x).P 1 | P 2 )), where f does not occur in P 1 and occurs in output position only in P 2 .

Let us analyse how our system imposes these constraints. In the rule for restriction on a functional name, the name g, that occurs in 'isolated position' in the conclusion of the rule, is added in the 'non isolated' part of the typing environment in the premise, with a type allowing one to use it in output only.

In the rules for input on an imperative name (replicated or not), the typing environment is of the form Γ •in the premise where we typecheck the continuation process: this has to be understood as Γ • d : o k T , for some dummy name d that is not used in the process being typed. We write '-' to stress the fact that we disallow the construction of replicated inputs on functional names. The functional name f appears in the aforementioned premise in the 'non isolated' part of the typing environment, with only the output rights on it. Forbidding the creation of replicated inputs on functional names under input Termination in a π-calculus with Subtyping prefixes is necessary because of diverging terms like the following (c is imperative, f is functional):

c(x).! f (y).x y | c f | f v .
Note also that typing non replicated inputs (on imperative names) involves the same constraints as for replicated inputs, like in [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF]: the relaxed control over functional names requires indeed to be more restrictive on all usages of imperative names.

The notation Γ •is also used in the rule to type a replicated input on a functional name, and we can notice that in this case f cannot be used at all in the premise, to avoid recursion.

In addition to the gain in expressiveness brought by subtyping, we can make the following remark:

Remark 18 (Expressiveness) As in [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], our system allows one to typecheck the encoding of a STλ term, by treating all names as functional, and assigning them level 0.

Moreover, our type system makes it possible to typecheck processes where several replicated inputs on the same functional name coexist, provided they occur 'at the same level' in the term. For instance, a term of the form (ν ν ν f ) (! f (x).P | ! f (y).Q | R) can be well-typed with f acting as a functional name. This is not possible using the def construct of [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF].

Another form of expressiveness brought by our system is given by typability of the following process:

!u(x).x | !v.u t | u v | c(y).u c .
Here, name c must be imperative while name v must be functional, and both are emitted on u. This is impossible in [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], where every channel carries either a functional or an imperative name. In our setting, only the output capability on c is transmitted along u, so in a sense c is transmitted 'as a functional name'.

Because of the particular handling of restrictions on functional names, the analogue of Lemma 5 does not hold for this type system: typability is not preserved by structural congruence. Accordingly, the subject reduction property is stated in the following way: Proof (sketch). The proof has the same structure as the corresponding proof in [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF]. An important aspect of that proof is that we exploit the termination property for the calculus where all names are functional without looking into it. To handle the imperative part, we must adapt the proof along the lines of the termination argument for Theorem 12.

Type Inference

We now study type inference, that is, given a process P, the existence of Γ, w such that Γ P : w. There might a priori be several such Γ (and several w: see Lemma 3). Type inference for level-based systems has been studied in [START_REF] Demangeon | On the Complexity of Termination Inference for Processes[END_REF], in absence of i/o-types. We first present a type inference procedure in a special case of our type system, and then discuss this question in the general case.

Type Inference for Termination in the Localised π-calculus

In this section, we concentrate on the localised π-calculus, Lπ, which is defined by imposing that channels transmit only the output capability on names: a process like a(x).x(y).0 0 0 does not belong to Lπ, as it makes use of the input capability on x. From the point of view of implementations, the restriction to Lπ makes sense. For instance, the language JoCaml [START_REF] Mandel | The JoCaml programming language[END_REF] implements a variant of the π-calculus that follows this approach: one can only use a received name in output. Similarly, the communication primitives in Erlang [START_REF]Erlang Programming Language Website[END_REF] can also be viewed as obeying to the discipline of Lπ: asynchronous messages can be sent to a PiD (process id), and one cannot create dynamically a receiving agent at that PiD: the code for the receiver starts running as soon as the PiD is allocated.

Technically, Lπ is introduced by allowing the transmission of o-types only. We write Γ Lπ P : w if Γ P : w can be derived in such a way that in the derivation, whenever a type of the form η k η k T occurs, we have η = o (types of the form i k T and k T appear only when typechecking input prefixes and restrictions). Obviously, typability for Lπ entails typability for , hence termination. It can also be remarked that in restricting to Lπ, we keep an important aspect of the flexibility brought by our system. In particular, the examples we have discussed in Section 3 -Example 15, and the encoding of the λ -calculus -belong to Lπ.

We now describe a type inference procedure for Lπ . For lack of space, we do not provide all details and proofs.

We first check typability when levels are not taken into account. For this, we rely on a type inference algorithm for simple types [START_REF] Vasconcelos | Principal Typing Schemes in a Polyadic pi-Calculus[END_REF], together with a simple syntactical check to verify that no received name is used in input. When this first step succeeds, we replace T types with oT types appropriately in the outcome of the procedure for simple types (a type variable may be assigned to some names, as, e.g., to name x in process a(x).b x ).

What remains to be done is to find out whether types can be decorated with levels in order to ensure termination. As mentioned above, we suppose w.l.o.g. that we have a term P in which all bound names are pairwise distinct, and distinct from all free names. We define the following sets of names:

• names(P) stands for the set of all names, free and bound, of P;

• bn(P) is the set of names that appear bound (either by restriction or by input) in P;

• rcv(P) is the set of names that are bound by an input prefix in P (x ∈ rcv(P) iff P has a subterm of the form a(x).Q or !a(x).Q for some a, Q);

• res(P) stands for the set of names that are restricted in P (a ∈ res(P) iff P has a subterm of the form (ν ν νa) Q for some Q).

We have bn(P) = rcv(P) res(P) (where stands for disjoint union), and names(P) = bn(P) fn(P). Moreover, for any x ∈ rcv(P), there exists a unique a ∈ fn(P) ∪ res(P) such that P contains the prefix a(x) or the prefix !a(x): we write in this case a = father(x) (a ∈ fn(P) ∪ res(P), because we are in Lπ). We build a graph as follows:

• For every name n ∈ fn(P) ∪ res(P), create a node labelled by n, and create a node labelled by son(n). Intuitively, if n has type k S of o k S, son(n) has type S. In case type inference for simple types returns a type of the form α, where α is a type variable, for n, we just create the node n.

• For every x ∈ rcv(P), let a = father(x), add x as a label to son(a). The next step is to insert edges in our graph, to represent the constraints between levels.

• For every output of the form n m , we insert an edge labelled with "≥" from son(n) to m.

• For every subterm of P of the form !a(x).Q, and for every output of the form n m that occurs in Q without occurring under a replication in Q, we insert an edge a > -→ n.

: : t t t t t t t t t t ≥ 4 4 i i i i i i i i i i i i i i i i i i i i i i son(b) ≥ / / {son(c), z}
The last phase of the type inference procedure consists in looking for an assignment of levels on the graph: this is possible as long as there are no cycles involving at least one > -→ edge in the graph. At the beginning, all nodes of the graph are unlabelled; we shall label them using natural numbers.

1. We go through all nodes of the graph, and collect those that have no outgoing edge leading to an unlabelled node in a set S .

2. If S is not empty, we label every node n in S as follows: we start by setting n's label to 0.

We then examine all outgoing edges of n. For every n ≥ -→ m, we replace n's label, say k, with max(k, k ), where k is m's label, and similarly for n > -→ m edges, with max(k, k + 1). We then empty S , and start again at step 1.

3. If S = / 0, then either all nodes of the graph are labelled, in which case the procedure terminates, or the graph contains at least one oriented cycle. If this cycle contains at least one > -→ edge, the procedure stops and reports failure. Otherwise, the cycle involves only ≥ -→ edges: we compute the level of each node of the cycle along the lines of step 2 (not taking into account nodes of the cycle among outgoing edges), and then assign the maximum of these labels to all nodes in the cycle. We start again at step 1. This procedure terminates, since each time we go back to step 1, strictly more nodes are labelled. As announced above, for lack of space we have described only the main steps of our type inference procedure. Establishing that the latter has the desired properties involves the introduction of an auxiliary typing judgement (that characterises Lπ ), and explaining how types are reconstructed at the end of the procedure. This finally leads to the following result:

Theorem 24 There is a type inference procedure that given a process P, returns Γ, w s.t. Γ Lπ P : w iff there exists Γ , w s.t. Γ Lπ P : w .

Discussion: Inferring i/o-Types

If we consider type inference for the whole system of Section 2, the situation is more complex. We start by discussing type inference without taking the levels into account. If a process is typable using simple types (that is, with only types of the form T ), one is interested in providing a more informative typing derivation, where input and output capabilities are used.

For instance, the process a(x).x t can be typed using different assignments for a: ioT , oT , i T , and T -if we suppose t : T . Among these, ioT is the most informative (intuitively, types featuring 'less #' seem preferable because they are more precise). Moreover, it is a supertype of all other types, thus acting as a 'candidate' if we were to look for a notion of principal typing. Actually, in order to infer i/o-types, one must be able to compute lubs and glbs of types, using equations like glb(iT, iU) = i glb(T,U), glb(iT, oU) = glb(T,U), and glb(oT, oU) = o lub(T,U). The contravariance of o suggests the introduction of an additional capability, that we shall note ↑, which builds a supertype of input and output capabilities (more formally, we add the axioms iT ≤↑ T and oT ≤↑ T ).

[7] presents a type inference algorithm for (an enrichment of) i/o-types, where such a capability ↑ is added to the system of [START_REF] Pierce | Typing and Subtyping for Mobile Processes[END_REF] (the notations are different, but we adapt them to our setting for the sake of readability). The use of ↑ can be illustrated on the following example process:

Q 1 de f
= a(t).b(u). !t(z).u z | c t | c u .

To typecheck Q 1 , we can see that the input (resp. output) capability on t (resp. u) needs to be received on a (resp. b), which suggests the types a : iiT, b : ioT . Since t and u are emitted on the same channel c, and because of contravariance of output, we compute a supertype of iT and oT , and assign type o ↑ T to c. Operationally, the meaning of ↑ is "no i/o-capability at all" (note that this does not prevent from comparing names, which may be useful to study behavioural equivalences [START_REF] Hennessy | Typed behavioural equivalences for processes in the presence of subtyping[END_REF]): in the typing we just described, since we only have the input capability on t and the output capability on u, we must renounce to all capabilities, and t and u are sent without the receiver to be able to do anything with the name except passing it along. Observe also that depending on how the context uses c, a different typing can be introduced. For instance, Q 1 can be typed by setting a : i T, b : ioT, c : ooT . This typing means that the output capability on u is received, used, and transmitted on c, and both capabilities on t are received, the input capability being used locally, while the output capability is transmitted on c.

The first typing, which involves ↑, is the one that is computed by the procedure of [START_REF] Igarashi | Type Reconstruction for Linear -Calculus with I/O Subtyping[END_REF]. It is "minimal", in the terminology of [START_REF] Igarashi | Type Reconstruction for Linear -Calculus with I/O Subtyping[END_REF]. Depending on the situations, a typing like the second one (or the symmetrical case, where the input capability is transmitted on c) might be preferable.

If we take levels into account, and try and typecheck Q 1 (which contains a replicated subterm), the typings mentioned above can be adapted as follows: we can set a : i 0 1 T, b : i 0 o 0 T, c : o 0 o 1 T , in which case subtyping on levels is used to deduce u : o 1 T in order to typecheck c u . Symmetrically, we can also set a : i 0 i 1 T, b : i 0 0 T, c : o 0 i 0 T , and typecheck c t using subsumption to deduce t : i 0 T .

It is not clear to us how levels should be handled in relation with the ↑ capability. One could think that since ↑ prevents any capability to be used on a name, levels have no use, and one could simply adopt the subtyping axioms i k T ≤↑ T and o k T ≤↑ T . This would indeed allow us to typecheck Q 1 .

Further investigations on a system for i/o-types with ↑ and levels is left for future work, as well as the study of inference for such a system.

Concluding Remarks

In this paper, we have demonstrated how Pierce and Sangiorgi's i/o-types can be exploited to refine the analysis of the simplest of type systems for termination of processes presented in [START_REF] Deng | Ensuring termination by typability[END_REF]. Other, more complex systems are presented in that work, and it would be interesting to study whether they would benefit from the enrichment with capabilities and subtyping. One could also probably refine the system of Section 2 by distinguishing between linear and replicated input capabilities, as only the latter must be controlled for termination (if a name is used in linear input only, its level is irrelevant).

The question of type inference for our type systems (differently from existing proposals, these are presented à la Curry, which is better suited for the study of type inference) can be studied further. It would be interesting to analyse how the procedure of Section 4.1 could be ported to programming languages that obey the discipline of Lπ for communication, like Erlang or JoCaml. For the moment, we only have preliminary results for a type inference procedure for the system of Section 2, and we would like to explore this further. Type inference for the system of Section 3.3 is a challenging question, essentially because making the distinction between functional and imperative names belongs to the inference process (contrarily to the setting of [START_REF] Demangeon | Termination in Impure Concurrent Languages[END_REF], where the syntax of processes contains this information).

Lemma 3

 3 If Γ P : w and w = 0 then for any w ≥ w, Γ P : w . Proposition 4 (Narrowing) If Γ, x : T P : w and T ≤ T , then Γ, x : T P : w for some w ≤ w. Lemma 5 If P ≡ Q, then Γ P : w iff Γ Q : w. Lemma 6 If Γ, x : T P : w, Γ b : T and T ≤ T then Γ P[b/x] : w , for some w ≤ w.

Figure 3 :

 3 Figure 3: Typing Rules for an Impure Calculus

Theorem 19 (

 19 Subject reduction) If Γ • f : o k T P : w and P -→ P , then there exist Q and w ≤ w s.t. P ≡ Q and Γ • f : o k T Q : w . Theorem 20 (Soundness) If Γ • f : o k T P : w, then P terminates.

Example 21

 21 We associate to the process P = a(x).(ν ν νb) x b | !a(y).(c y | d(z).y z ) the following set of 8 nodes with their labels: {a}, {son(a), x, y}, {b}, {son(b)}, {c}, {son(c), y}, {d}, {son(d), z}.

Example 22

 22 The graph associated to process !c(z).b z | a c | a b has nodes {a}, {son(a)}, {b}, {son(b)}, {c}, {son(c), z} , and can be depicted as follows:

Example 23

 23 On the graph of Example 22, the procedure first assigns level 0 to nodes a, b and {son(c), z}. In the second iteration, S = {son(b), c}; level 0 is assigned to son(b), and 1 to c. Finally, level 1 is assigned to son(a). This yields the typing b : o 0 o 0 T, c : 1 o 0 T, a : o 0 o 1 o 0 T for the process of Example 22.

Termination in a π-calculus with Subtyping Subtyping ≤ is the least relation that is reflexive, transitive, and satisfies the following rules:k T ≤ i k T k T ≤ o k T T ≤ S k 1 ≤ k 2 i k 2 T ≤ i k 1 S T ≤ S k 1 ≤ k 2 o k 1 S ≤ o k 2 TTyping valuesΓ : U Γ(a) = T Γ a : T Γ a : T T ≤ U Γ a : U Typing processes Γ 0 0 0 : 0 Γ a : o k T Γ v : T Γ a v : k Γ a : i k T Γ, x : T P : w Γ a(x).P : w Γ a : i k T Γ, x : T P : w k > wΓ !a(x).P : 0 Γ, a : T P : w

Acknowledgements. Romain Demangeon, as well as anonymous referees, have provided insightful comments and suggestions on this work. We also acknowledge support by ANR projects ANR-08-BLANC-0211-01 "COMPLICE", ANR-2010-BLANC-0305-02 "PiCoq" and CNRS PEPS "COGIP".