des types
La syntaxe du calcul n’est que très légèrement modifiée pour ajouter des passeports contrôlant les migrations. En particulier la syntaxe des identifiants, valeurs et motifs donnée figure 1.1 est intégralement conservée. Il en est de même pour la syntaxe des systèmes. Les modifications et ajouts à la syntaxe des processus sont résumés à la figure 4.1.
La première modification nécessaire est l’indication explicite du passeport utilisé lors d’une migration : la migration est alors notée gotovu. P où v est l’identifiant du passeport rendant l’accès à la localité u possible depuis la localité courante. Les autres modifications de la syntaxe rendent possible la création de ces passeports.
La première façon de créer de nouveaux passeports est d’utiliser la primi- tive newpass p from ˜u qui crée un nouveau passeport, de nom p, permettant de venir des localités ˜u. Le fait qu’il s’agisse d’un ensemble de localités permettra de modéliser la confiance existant au sein d’un sous-réseau, où le même passe- port peut être utilisé quelle que soit la localité de départ. Bien entendu, pour que les passeports permettent effectivement un contrôle des migrations, il est indispensable que seuls les processus s’exécutant au sein d’une localité puissent créer un passeport en autorisant l’accès. C’est pourquoi la primitive permettant de générer un nouveau passeport se contente d’indiquer les localités d’origine où ce passeport pourra être utilisé, la destination sera toujours la localité courante. La réduction du préfixe newpass p from ˜u se chargera alors de prendre en compte la localité courante pour donner un type au passeport p.
Il sera aussi possible de créer des passeports autorisant l’entrée dans la localité quelle que soit la localité d’origine, en utilisant la primitive newpass p from ?, où ? peut se lire comme « n’importe où ». Ces passeports seront particulièrement adaptés à la description de comportements de serveurs, c’est-à-dire de localités publiquement accessibles.
La dernière modification de la syntaxe concerne les créations de localité, afin de pouvoir créer des passeports en même temps que la localité. En effet, si on considère le système lJnewloc k with Pkin PK, le processus P ne pourra pas migrer vers la nouvelle localité k sans disposer d’un passeport spécifique. De plus, Pk n’aura le droit de migrer vers la localité l que s’il connaît un passeport universel pour y entrer, puisqu’il ne peut pas encore exister de passeport mentionnant le nouveau nom de localité k. Afin d’éviter ces blocages, la génération de localités est généralisée pour prendre la forme
newloc k, (c1, . . .), (p1, . . .), (q1, . . .) : L with Pkin P
où k et les ci, piet qi sont de nouveaux noms. k est la nouvelle localité, c1, . . . un ensemble de canaux situés dans k, p1, . . . des passeports permettant d’entrer dans k et enfin q1, . . . des passeports pour entrer dans l, si l est la localité dans laquelle k est créée. Ainsi, les passeports pi peuvent autoriser des migrations de l vers k et les passeports qj celles de k vers l. La création de ces passeports et de ces canaux en même temps que la localité permet par ailleurs que ces noms soient connus par le processus P . Cette fonctionnalité rend élégante l’écriture de l’exemple du sas que nous avons vu précédemment : les droits de migration entre le sas et le client peuvent être réduits au strict minimum (un passeport permettant de migrer de sas vers cl), tout en autorisant le client à envoyer directement sa requête au serveur car il dispose du nom du canal réssassur lequel
la réponse doit être retournée et du passeport passsas nécessaire pour le serveur. L’ajout des passeports suppose bien entendu l’ajout de types pour cette nouvelle catégorie de noms et de variables. Puisque les types apparaissent syntaxiquement dans les systèmes, voyons les types associés aux passeports avant les nouvelles règles de la sémantique.
Les modifications de la syntaxe des pré-types sont données à la figure 4.2. À un passeport autorisant les migrations vers la localité l partant de l’une des
Fig. 4.2 Modifications des pré-types (voir 2.1)
P ::= Types de passeports
˜
s 7→ t Passeport
? 7→ t Passeport universel E ::= Types des identifiants
loc Localité
C@s Canal localisé à s
P Passeport
L ::= Types déclaratifs de localité
P x : loc. P y : loc. (C1@y, . . .), (˜u?17→ y, . . .), (˜v1?7→ x, . . .)
localités de l’ensemble {k1, . . . , kn} on associera le type1 k1, . . . , kn 7→ l. Pour un passeport universel, on utilisera un type ? 7→ l. On dénotera cette nouvelle famille de types par la lettre P, famille qui s’ajoute à celles des types possibles pour les identifiants.
Par contre la modification des types déclaratifs de localité est plus complexe. Tout comme dans le cadre du chapitre 2, le type déclaré pour les localités devra permettre d’associer un type de la forme C@l à tous les canaux qui sont créés
en même temps que l, où l est la nouvelle localité. Mais on veut aussi spécifier le type à attribuer aux différents passeports, aussi bien ceux autorisant l’accès à la nouvelle localité l que ceux permettant d’accéder à la « localité-mère », c’est-à-dire la localité où newloc est exécuté. Suivant la même approche que pour les types des canaux, on peut facilement imposer que la localité à laquelle la première famille de passeports donne accès soit une variable liée qui sera instanciée par la localité en cours de création, par exemple en écrivant :
k, (c1, . . .), (p1, . . .) : X
y : loc. (C1@y, . . .), (˜u?17→ y, . . .)
L’expansion attribuera alors un type de la forme attendue à chacun des passe- ports pi. La notation ˜u?1apparaissant dans le type ˜u
?
17→ y désignera uniformément soit ˜u1 soit ?. ˜u?1 7→ y désignera ainsi soit un type de la forme ˜u17→ y soit un type de la forme ? 7→ y.
Pour la seconde famille de passeports, qi, donnant accès à la localité-mère, on adapte cette idée, de sorte que les types déclaratifs de localité auront la forme
X
x : loc. Xy : loc. (C1@y, . . .), (˜u?17→ y, . . .), (˜v?17→ x, . . .)
où x sera instanciée par la localité-mère et y par la localité-fille nouvellement créée.
Même si les types déclaratifs de localité utilisent une somme dépendante pour la localité-mère et la localité-fille, ces deux localités auront un statut sémantique totalement différent dans cette construction. Les quelques règles qui doivent changer sont données figure 4.3. On y voit en particulier que la règle de réduction du préfixe newloc effectue immédiatement la substitution de la première variable
1Les k
iapparaissant dans le type forment un ensemble, pas une liste. a, b 7→ l et b, a 7→ l
sont deux notations du même type.
Fig. 4.3 Modifications de la sémantique par réductions (voir figure 1.4)
(r-goto) lJgotopk. PK −→ kJP K
(r-newloc)
lJnewloc k, (~c), (~p), (~q) :P x : loc. T with Pkin PK −→ (newk, ((~c), (~p), (~q)) : T{l/x} )(k
JPkK | lJP K) (r-newpass) lJnewpass p from˜k
?in P
K −→ (new p :˜k ?7→ l) l
JP K
Fig. 4.4 Règles inductives supplémentaires de sous-typage (voir 2.4)
˜ s0⊆ ˜s (sr-pass)
Σ ` ˜s 7→ t <: ˜s07→ t (sr-pass-*) Σ ` ? 7→ t <: ˜s ?7→ t
liée. En effet on utilise une variable liée pour la localité-mère dans les types L uniquement pour garantir que les passeports (qi) qui sont engendrés lors de cette réduction permettent d’accéder à la localité-mère, et non à une localité quelconque. Il ne faut pas pour autant que la sémantique lie le nom de la localité- mère, donc on ne peut pas utiliser la notation (newhl, (k, ((˜c), (˜p), (˜q))) : Li@l) qui
correspondrait à une suite de new commençant par (new l : loc). C’est pourquoi la règle (r-newloc) substitue immédiatement la première variable du type L par le nom de la localité l où la réduction a lieu.
La règle de réduction (r-goto) modifiée peut paraître un peu surprenante : le seul changement qu’elle subisse est l’annotation du passeport utilisé pour la migration, mais elle ne dépend pas de ce passeport. Exactement comme dans la réduction des communications
lJa ! hV i P1K | lJa ? (X : T) P2K −→ lJP1K | lJP2{ V/X}
K
où la validité de la substitution {V/X} est tout simplement ignorée, le nom du passeport employé pour effectuer une migration ne joue aucun rôle dans la réduction. Sa validité découlera en revanche du typage qui sera imposé sur les systèmes. Par ailleurs, il est malgré tout indispensable de mentionner explicitement le nom du passeport dans la primitive de migration pour que ce nom soit libre dans le processus migrant : c’est la condition sine qua non pour que les règles de la congruence structurelle puissent s’appliquer normalement. La dernière règle ajoutée à la sémantique qui sert à créer les passeports est sans surprise.
Les types de passeport rajoutés à la syntaxe ne modifient que superficiellement la structure de l’ensemble des types. Il est en particulier très facile de rajouter des règles de sous-typage et de bornes inférieure et supérieure qui les prennent en compte. De par la forte similitude entre les règles inductives avec la mémoire Σ données aux figures 2.4, 2.5 et 2.6, et les fonctions des figures 2.2 et 2.3 servant à les définir dans le cadre coinductif, on se contentera de définir le cas récursif. En particulier, ces règles seront des axiomes puisque les types de passeport sont des types de base. Les règles supplémentaires sont alors données aux figures 4.4 et 4.5.
Fig. 4.5 Règles inductives supplémentaires pour u (voir 2.5) et t (voir 2.6) (meet-pass) Σ ` ˜s 7→ t u ˜s07→ t = ˜s, ˜s07→ t (meet-pass-*-g) Σ ` ? 7→ t u ˜s?7→ t = ? 7→ t (meet-pass-*-d) Σ ` ˜s?7→ t u ? 7→ t = ? 7→ t ˜ s 6= ∅ et ˜t ∩ ˜t0= ∅ (join-pass) Σ ` ˜s, ˜t 7→ s t ˜s, ˜t07→ s = ˜s 7→ s (join-pass-*-g) Σ ` ? 7→ s t ˜s 7→ s = ˜s 7→ s (join-pass-*-d) Σ ` ˜s 7→ s t ? 7→ s = ˜s 7→ s (join-pass-*-gd) Σ ` ? 7→ s t ? 7→ s = ? 7→ s
Ces nouveaux pré-types ne modifient par contre en rien la théorie des types. En particulier, la définition 2.4, listant les conditions auxquelles un pré-type est un type, est inchangée : les contraintes de fermetures des portées des identifiants s’appliquent aussi aux identifiants apparaissant dans ces nouveaux types, pour lesquels les définitions des noms, variables et variables de récursion libres sont aisément étendues. Par ailleurs, tous les résultats sur l’ordre <: et les opérateurs u et t obtenus dans le cadre coinductif, notamment le théorème 2.17 de complétude sous condition, restent applicables sur ces types.