La relation de r´eduction

Comme nous l’avons introduit pr´ec´edemment, la s´emantique op´erationnelle

du langage_Oz/K est d´efinie par une relation entre des structures d’ex´ecution

(σ,T). Comme pour les calculs pr´ec´edemment, cette relation est introduite par

un ensemble de r`egles de r´eduction, pr´esentant de mani`ere formelle le

comporte-ment de chacune des commandes du langage. Nous adoptons dans cette partie la

mˆeme approche envers la s´emantique op´erationnelle que le chapitre 13 de [110],

et en particulier, nous adoptons la mˆeme notation pour les r`egles de r´eduction.

En effet, cette formulation des r`egles, d´efinie pour le langage_Oz, est

relative-ment bien adapt´ee pour g´erer `a la fois des stores et des tˆaches. De plus, le fait

d’utiliser le mˆeme formalisme que celui dans lequel a ´et´e d´efini la base de notre

langageOz/K, montre avec clart´e que ce langage est bien une extension qui ne

modifie en aucun cas les fondements deOz, et qui ne pourrait ˆetre encod´ee avec

les op´erations de base deOz. Les r`egles d’inf´erence pour d´efinir la r´eduction du

langage Oz/K prend la forme suivante, cette r`egle signifiant que la structure

d’ex´ecution (σ,T) se r´eduit en (σ

⁰

,T

0

) sous la conditionC :

T T

0

σ σ

⁰

^{si C}

Quelques d´efinitions pr´eliminaires

Comme dans les calculs pr´ec´edents, nous introduisons la s´emantique

op´era-tionelle de notre langage par un ensemble de d´efinitions donnant les bases sur

lesquelles sont fond´ees nos r`egles de r´eduction.

L’´equivalence structurelle. Cette relation de r´eduction fontionne modulo

une relation d’´eqauivalence structurelle sur les termes manipul´es (tˆaches et

stores) qui identifie les ´el´ements de s´emantique semblable. La Figure 5.6 pr´esente

l’´equivalence structurelle entre les tˆaches, qui identifie les termes du calcul

mo-dulo αconversion. Les tˆaches sont identifi´ees modulo associativit´e et

commu-tativit´e des processus l´egers : ces derniers s’ex´ecutant en parall`ele, l’ordre dans

lequel ils sont d´eclar´e n’a pas d’importance.

S1≡αS2

S1≡S2

T1T2≡ T2 T1 T1(T2T3)≡(T1T2) T3

T1≡ T2

T1T ≡ T2T

Figure5.6 – La relation d’´equivalence entre tˆaches

L’´equivalence structurelle pour les stores, pr´esent´ee Figure 5.7, est elle aussi

assez concise. L`a encore, les ´el´ements du store, d´eclarant simplement les diff´erents

objets construits par le programme durant son ex´ecution, peuvent permuter

li-brement. De plus, les ´egalit´es impliquant des termes du calcul ´equivalents sont

elles aussi ´equivalentes.

La s´emantique des stores. Afin de simplifier la manipulation des stores,

nous d´efinissons une syntaxe simple de contrainte, donnant quels ´el´ements sont

d´eclar´es si une variable est li´ee ou non, si deux variables sont unifiable, etc.

Cette syntaxe est donn´ee Figure 5.8. Afin de ne pas avoir de doublons, nous

utilisons dans cette figure le symbolepour d´enoter soit une variablexsoit un

nom ξ. `a partir de ces contraintes, nous construisons Figure 5.9 le pr´edicat

entre un storeσet une contrainteφ, d´efinissant quand un store valide une telle

σ1≡σ3 σ2≡σ4

σ1∧σ2≡σ4∧σ3

T1≡ T2 σ1≡σ2

x=pack(ξ,T1, σ1, M)≡x=pack(ξ,T2, σ2, M)

S1≡S2

ξ:proc{P X1. . . Xn}S1end≡ξ:proc{P X1. . . Xn}S2end x=y≡y=x

Figure5.7 – La relation d’´equivalence entre les stores

φ ::= σ | x=⊥ | V _onV | ¬φ | ∃.φ | ∀.φ | φ∧φ | φ∨φ

Figure5.8 – Les contraintes de store

contrainte. Informellement, ce pr´edicat est r´eflexif et transitif (dans le sens o`u

un store est une contrainte). De plus, la d´eclaration de valeur dans un store est

transitive : six=y ety=V sont dans le mˆeme store, ce la signifie quey=V,

mais aussi quex=V. Les autres r`egles pr´esent´ees dans la Figure d´efinissent la

signification de chaque terme de contrainte. Par exemple, la contraintex=⊥

signifie que la variable x est d´eclar´ee dans le store, mais n’est pas li´ee `a une

valeur. De mani`ere similaire, la contrainteV onV

0

signifie que ces deux valeurs

sont unifiables. Finalement, les six derni`eres r`egles montre comment les lieurs

classiques de la logique et les op´erateurs de n´egation¬et de disjonction∨sont

interpr´et´es dans notre s´emantique. La s´emantique de ces lieurs est construite

`a partir de deux fonctions sur les stores : v et n qui donnent respectivement

les variables et les noms d´eclar´es dans le store en param`etre. Plus pr´ecisement,

nous pouvons d´efinir les ensemblesn(σ) etv(σ) comme suit :

n(σ),{ξ| ∃E, σx=ξ∨ξ:E}

v(σ),{x| ∃V, O, σx∨x=V ∨failed(x)∨thread(x)∨kell(O, x)})

Les stores non valides. Les stores de notre langage ont un grand pouvoir

d’expressions, ce qui nous permet de connaˆıtre beaucoup de chose sur l’ex´ecution

σσ ^σ1σ2 σ2σ3 σ1 σ3 σφ1∧φ2 σφ1 σφ1 σφ2 σφ1∧φ2 σy=V ∧x=y σx=V σx ∀V, σ6x=V σx=⊥ V ≡V⁰ σV _onV⁰ σV1onV2∧V2onV3 σV1onV3 σx=⊥ σx_onV σx=V ∧V _noV⁰ σx_noV⁰ σx_ony σfailed(x)_onfailed(y) σx1nox⁰₁∧ · · · ∧xnonx⁰_n σl(a1:x1, . . . , an:xn)_onl(a1:x⁰1, . . . , an:x⁰n) σ6φ σ¬φ σφ σφ∨φ⁰ ∀x∈v(σ), σφ σ∀x.φ ∀ξ∈v(σ), σφ σ∀ξ.φ ∃x∈v(σ), σφ σ∃x.φ ∃ξ∈v(σ), σφ σ∃ξ.φ

Figure 5.9 – La s´emantique des stores

en cours d’un programme. Nous pouvons en effet connaˆıtre l’´etat des threads,

les valeurs li´ees `a chaque variables, savoir quelles contraintes d’´egalit´e entre

diff´erentes variables ont ´et´e d´eclar´ees. Mais ce pouvoir d’expression a aussi

l’in-conv´enient de permettre `a un store d’ˆetre incoh´erent. En effet, il est possible

dans un store σ de lier une variable x `a deux valeurs diff´erentes, d’avoir une

structure de kell qui forme des cycles, etc. Nous pr´esentons Figure 5.10 une

contrainteφqui d´efinit quand un store contient une incoh´erence :

D´efinition 11. Un store σ est dit incoh´erent ou invalide s’il existe V, V

0

, et

pour toutO, O

0

nous avonsσφ(avecφd´efinie Figure 5.10).

La contrainte φ est compos´ee de six disjonctions, chacune d’elles pr´ecisant

une condition d’invalidit´e du store. La premi`ere cause d’invalidit´e est, tel que

nous l’avons signal´e, une variable li´ee `a diff´erentes valeurs non unifiables. La

seconde et la troisi`eme cause concerne la structure des kells. En effet, ces

com-posants doivent imp´erativement ˆetre assembl´es dans une structure d’arbre

en-racin´e, et un store validant une de ces clauses de la contrainte aurait soit un

cycle dans l’assemblage, soit un composant avec deux p`eres, ce qui est

inter-dit. La quatri`eme clause est semblable `a la troisi`eme, et sp´ecifie qu’un thread

cette fois ne peut avoir deux composants englobant. Les deux derni`eres clauses

donnent que les d´eclarations d’inclusion ne peuvent ˆetre faites qu’entre des noms

correspondant `a des kells, ou `a des threads dans des kells.

∃x, x=V ∧x=V⁰∧ ¬(V _onV⁰) (1)

∨ ∃κ1, κ2,in(κ1, κ2)∧in(κ2, κ1) (2)

∨ ∃κ16=κ2, κ,in(κ1, κ)∧in(κ2, κ) (3)

∨ ∃κ16=κ2, ξ,inth(κ1, τ)∧in(κ2, τ) (4)

∨ ∃κ, κ⁰,∀x, x⁰,in(κ, κ⁰)∧ ¬(κ:kell(O, x)∧κ⁰:kell(O⁰, x⁰)) (5)

∨ ∃κ, τ,∀x, x⁰,inth(κ, τ)∧ ¬(κ:kell(O, x)∧τ:thread(x⁰)) (6)

Figure 5.10 – La contrainteφd´efinissant les stores invalides

L’extension de la s´emantique des stores. Afin de d’avoir une pr´esentation

lisible de la s´emantique des stores, nous avons donn´e pr´ec´edemment une syntaxe

des contraintes de storeφrelativement simple et suffisante pour d´ecrire quand

un store est invalide. Cette syntaxe est maintenant ´etendue Figure 5.11 par deux

nouvelles constructions, sp´ecifiques `a la manipulation des kells et des ´echanges

de messages entre composants. La premi`ere construction que nous rajoutons est

φ ::= . . . | strict(V) | access(ξ, ξ, ξ)

Figure5.11 – L’extension des contraintes de store

strict(V), qui est valide si et seulement si la valeurV eststricte. Une valeur est

ditestrictequand elle est totalement d´efinie, qu’elle ne poss`ede aucune r´ef´erence

vers des variables non li´ees, comme cela est pr´ecis´e Figure 5.12. Ce pr´edicat est

fort utile dans les r`egles de communications entre composants, pour s’assurer

que les portes n’´echangent que des valeurs strictes, sans variable non li´ee qui

pourraient conduire `a la perte de l’isolation et du contrˆole des communications

entre ces composants. Le second pr´edicat estaccess(ξ, κ1, κ2). Il d´efinit quand

la porte ξ peut ˆetre utilis´ee pour la communication entre κ1 et κ2. Comme

cela a ´et´e pr´ecis´e pr´ec´edemment, les communications sont toujours autoris´ees `a

l’int´erieur d’un mˆeme composant, et entre un composant et ses fils. Le reste de la

σstrict(u) σstrict(pack(ξ,T, σ, M)) ^σξ:gate∨ ¬ξ:E σstrict(ξ) σstrict(v)∧x=v σstrict(x) σstrict(x) σstrict(failed(x)) σstrict(x1)∧ · · · ∧strict(xn) σstrict(l(a1:x1, . . . , an:xn))

σξ:proc{$X1. . . Xn}Send ∀x∈v(S), σstrict(x)

σstrict(ξ)

Figure5.12 – La s´emantique destrict

s´emantique de ce pr´edicat suit ce mˆeme principe : toute communication ne peut

franchir qu’une seule fronti`ere de composant. L’ouverture d’une porte a un effet

similaire `a la destruction d’une fronti`ere pour les communications passant sur

cette porte, et permet ainsi d’avoir des communications distantes. La s´emantique

de ce pr´edicat est ainsi bas´e sur une notion de distance d´efinissant combien de

fronti`eres sont plac´ees entre deux composants, pour une porte donn´ee. Cette

distance est donn´ee Figure 5.13 comme une relationσdist(ξ, κ1, κ2, n). Une

telle relation d´efinit qu’il existe dans le store σ un chemin de communication

sur la porteξ, entre les composantsκ1etκ2, et qui ne franchit quenfronti`eres.

Bien sˆur, il existe plusieurs chemins entre deux composants. Par exemple, entre

deux composants fr`eres, il existe un chemin passant simplement par le p`ere, mais

aussi un autre passant par le p`ere, le grand-p`ere, puis de nouveau par le p`ere.

Il existe n´eanmoins un plus court chemin, qui correspond au nombre minimal

de fronti`eres `a franchir. Nous pouvons donc d´efinir le pr´edicataccess(ξ, κ1, κ2)

comme suit :

σdist(ξ, κ1, κ2, n) n≤1

σaccess(ξ, κ1, κ2)

Les sous-threads et les sous-kells. Nous utilisons deux nouvelles fonctions

sur les stores, calculant tous les sous-composants d’un composant donn´e, et tout

les threads que ces composants ex´ecutent. La fonctionsubk, calculant l’ensemble

des sous composants `a partir d’une paire (σ, ξ), est d´efinie r´ecusivement comme

σκ=kell(O, x) σdist(ξ, κ, κ,0) σdist(ξ, κ1, κ2, n) σin(κ2, κ3) σκ2=kell(O, x) κ3·ξ∈O σdist(ξ, κ1κ3, n) σdist(ξ, κ1, κ2, n) σin(κ2, κ3) σκ2=kell(O, x) κ3·ξ6∈O σdist(ξ, κ1κ3, n+ 1) σdist(ξ, κ1, κ2, n) σin(κ3, κ2) σκ3=kell(O, x) κ2·ξ∈O σdist(ξ, κ1κ3, n) σdist(ξ, κ1, κ2, n) σin(κ3, κ2) σκ3=kell(O, x) κ2·ξ6∈O σdist(ξ, κ1κ3, n+ 1)

Figure5.13 – La relation de distance entre deux composants

suit :

K,{ξ

⁰

|σξ:kell(O, x)∧in(ξ, ξ

⁰

)∧ξ

⁰

:kell(O

⁰

, x

⁰

)∧x

⁰

=⊥}

subk(σ, ξ), ^[

ξ0∈K

subk(σ, ξ

⁰

)∪K

Cette d´efinition est assez claire : les descendants d’un composant sont ses fils

(d´efinis par l’ensembleK), et les descendants de ces fils. Il est facile, `a partir de

cette d´efinition de sous-composants, de construire la fonctionsubth qui donne

les threads s’ex´ecutant dans un composant. Cette fonction prend elle aussi une

paire (σ, ξ) en param`etre, o`uξest le composant contenant les threads voulus :

T(ξ

⁰

),{ξ

t

|σinth(ξ

⁰

, ξ

t

)}

subth(σ, ξ), ^[

ξ0∈subk(σ,ξ)

T(ξ

⁰

)

Les abr´eviations. Finalement, la derni`ere notion que nous introduisons avant

la pr´esentation des r`egles de r´eduction sont les abr´eviations que nous utilisons

pour simplifier nos r`egles. Ces facilit´es d’´ecriture sont r´esum´ees Figure 5.14.

Nous utilisons une derni`ere abr´eviation dans nos r`egles : S|

σ

κ

. Ce terme n’est

valide que s’il existe un threadξtel queσinth(κ, ξ), et correspond `a la tˆache

ξhS Ti, pour unT qui n’est pas modifi´e par la r`egle de r´eduction.

La r`egle est une abr´eviation pour S S⁰ σ σ^{0 si C} ξhS Ti ξhS⁰ Ti σ σ^{0 si C} T T0 σφ σ^{0 si C} T T0 σ σ^{0 si C}∧σφ

Figure5.14 – Les deux abr´eviations principales

Les r`egles de r´eduction

Nous donnons finalement dans cette partie les r`egles principalesd´efinissant

la s´emantique op´erationnelle de notre langage. Nous ne donnons pas par exemple

toutes les r`egles d’erreur, qui s’appliquent quand celles donn´ees ici ne peuvent

l’ˆetre, et dont le seul effet est la lev´ee d’une exception correspondant `a l’erreur

rencontr´ee. Dans la suite, nous pr´esentons chaque r`egle individuellement, afin

d’ˆetre clair sur tout les d´etails les concernant.

Les r`egles structurelles. Nous avons deux r`egles simple d´efinissant dans

quel contexte une tˆache peut s’ex´ecuter. La premi`ere montre que ces processus

sont bien en parall`ele, et s’ex´ecutent de mani`ere ind´ependante :

T T0 T0 T

σ σ^{0 si}

T T0

σ σ⁰

La seconde est encore plus simple, et ´etablit que la relation de r´eduction est

bien d´efinie modulo la relation d’´equivalence entre tˆaches et entre les stores :

T1 T2

σ1 σ2

si T3 T4

σ3 σ4

etT1≡ T3∧ T2≡ T4∧σ1≡σ3∧σ2≡σ4

Les r`egles d’ex´ecution s´equentielle. Nous avons trois r`egles d´efinissant

comment se comportent les diff´erentes ´el´ements de la s´emantique s´equentielle

du langage. La premi`ere donne comment le mot clefskipse comporte : ce mot

clef correspond `a l’instruction vide, et n’a aucun effet sur le store ou les autres

tˆaches.

ξhskip Ti ξT

σ σ

La seconde r`egle montre comment les diff´erentes d´eclarations d’un termeSsont

d´ecompos´ees pour ˆetre ensuite ex´ecut´ees :

ξh(S1S2) Ti ξhS1 hS2 Tii

Et finalement, la troisi`eme r`egle pr´esente comment se passe l’arrˆet normal d’une

tˆache. La variable de status, suppos´ee non li´ee se voit alors affecter la valeur

terminated, signifiant ainsi que la tˆache s’est ex´ecut´e sans probl`eme.

ξhi

σξ:thread(x)∧x=⊥ σ∧x=terminated

La r`egle de cr´eation de thread. Un thread est cr´e´ee par la commande de

construction de threadthread{x}Send. Durant cette cr´eation, la r`egle utilise

un nouveau nomξ

⁰

qui repr´esente le nouveau thread, et une nouvelle variable

x

0

qui est la variable de status de ce thread. Ce nouveau thread est mis en place

par la nouvelle tˆache ξ

⁰

hS hii, qui est plac´ee dans le mˆeme kell que la tˆache

d’origine.

ξhthread{x}Send Ti ξT ξ⁰hShii

σx=⊥ ∧inth(κ, τ) σ∧x=ξ⁰∧ξ⁰:thread(x⁰)∧x⁰∧inth(κ, ξ⁰) si ξ⁰, x⁰fresh

La r`egle de cr´eation de variables. Cette r`egle est relativement simple, et

a pour effet de remplacer les variables formelles du langage par des nouvelles

variables du store.

local X1. . . Xnin Send S{x_i/X_i}

σ σ∧x1∧ · · · ∧xn

avec xi fresh

Les r`egles d’affectation de variable. Contrairement `a la plupart des

lan-gages logiques, et en particulier, contrairement `a_Oz, les d´eclarations d’´egalit´e

ne font pas intervenir d’unification. Ce choix est motiv´e par plusieurs probl`emes

que peut poser l’application automatique de l’unification lors de l’utilisation

du pr´edicat d’´egalit´e. Par exemple, l’unification est une op´eration tr`es couteuse,

alors que l’affectation d’une valeur `a une variable est quasi-instantan´ee. De plus,

ne pas avoir d’unification permet d’´eviter des erreurs de programmation, telles

que donner une valeurV `a une variablex, pensant qu’elle est libre, alors qu’elle

ne l’est pas. Sans unification, l’erreur l`eve une exception durant l’ex´ecution du

programme, et peut ainsi ˆetre facilement corrig´ee. Avec une unification, il est

possible queV soit unifiable avec celle que contient d´ej`ax. L’erreur ne sera donc

pas visible, et pourra mˆeme causer des disfonctionnement du programme par la

suite, xne contenant pas V, mais l’unification de cete valeur avec une autre.

L’unification, op´eration de base des langages logiques, est tout de mˆeme int´egr´e

au langage, sous forme d’une proc´edureUnifyS. L’effet de cette proc´edure n’est

pas pr´esent´e ici, car il est identique `a l’unification telle qu’elle est pr´esent´ee dans

le chapitre 13 de [110].

Nous avons trois r`egles d’affectation. La permi`ere concerne la liaison d’une

variable `a une valeur, telle qu’un entier ou un message structur´e. Comme nous

l’avons pr´ecis´e, cette r`egle ne peut s’appliquer sixposs`ede d´ej`a une valeur :

x=V skip

σx=⊥ σ∧x=v ^{si V} 6∈Var

La seconde pr´esente la s´emantique de la d´eclarationx=y. Afin d’´eviter

l’uni-fication, cette d´eclaration est ajout´ee au store si et seulement si au maximum

une variable parmisxety poss`ede une valeur :

x=y skip

σx=⊥ ∨y=⊥ σ∧x=y

Finalement, la derni`ere r`egle pr´esente comment l’acc`es aux champs d’un

mes-sage structur´e s’effectue :

x=x⁰.z skip

σx=⊥ ∧x⁰=l(a1:x1, . . . , an:xn)∧a=fi σ∧x=xi

La r`egle de lecture du status. Nous proposons ici de montrer la s´emantique

d’une proc´edure de base, la proc´edureStatus, qui retourne le status d’un

proces-sus l´eger. Il est `a noter qu’il est seulement possible de connaˆıtre le status d’un

thread s’ex´ecutant dans le composant courant, afin de garantir la s´eparation

entre les kells d’un mˆeme programme.

ξh{Statusx y} Ti ξhTi

σ σ∧y=z ^{si σ y=⊥ ∧x=ξ}

0∧ξ⁰:thread(z)

∧inth(κ, ξ)∧inth(κ, ξ⁰)

Les r`egles pour la conditionnelle. La s´emantique de la commande

condi-tionnelleif xthen S1else S2endest classique, identique `a celle pr´esent´ee

pour le langageOz. Elle est construite `a partir de deux r`egles de r´eduction. La

premi`ere est appliqu´ee lorsque la condition de la commande est valid´ee :

if xthen S1else S2end S1

σx=true σ

La seconde r`egle est utilis´ee lorsque la condition de la commande n’est pas

valid´ee :

if xthen S1else S2end S2

σx=false σ

Les r`egles pour le filtrage de motif. La commande pour le fitrage de

motif case x of J then S1 else S2 du langage _Oz est similaire `a la

conditionnelle pr´esent´ee pr´ec´edemment, dans le sens o`u nous avons deux cas :

soit le filtrage fonctionne, auquel casS1est ex´ecut´e, soit il ne fonctionne pas (la

condition n’est pas valid´ee), et c’estS2qui sera ex´ecut´e dans ce cas. Nous avons

une fonction,match, qui prend en param`etre un triplet (σ, x, J) et qui renvoie

une substitution dans le cas o`u le filtrage fonctionne (la substitution d´efinit les

valeurs des diff´erentes variables non li´ees du motif). Si le filtrage ne fonctionne

pas, la fonction renvoie alors⊥. Les cas ou le filtrage est valid´ee sont pr´esent´es

Figure 5.15 (les cas non pr´esent´es dans cette figure correspondent aux echecs

du filtrage). Cette figure est constitu´ee de trois colonnes : la premi`ere donne

quelle condition le store doit valider pour que le fitrage soit valide. La seconde

donne la forme du filtre, et la troisi`eme donne la substitution calcul´ee par la

fonctionmatch. Notons que la substitutionIdest l’identit´e qui ne modifie aucune

variable. Avec cette fonction match nous pouvons ais´ement d´efinir la r`egle de

φ J match(σ, x, J) x=v v Id x=v∧y=v y Id x=v∧y=⊥ X [X7→v] Vn i=1ai=a⁰i∧l=l⁰ ∧x=l(a1:x1, . . . , an:xn) ^l 0 (a⁰₁:X1, . . . , a⁰_n:Xn) [Xi7→xi]

Figure5.15 – La fonctionmatch

r´eduction pour un filtrage valide :

case xof Jthen S1else S2 θ(S1)

σ σ ^{si match(σ, x, J) =θ}

La r`egle pour un echec de filtrage est aussi relativement simple :

case xof Jthen S1else S2 S2

σ σ ^{si match(σ, x, J) =}⊥

Les r`egles pour la cr´eation et l’utilisation des proc´edures. Notre

s´e-mantique op´erationnelle comprend trois r`egles pour la manipulation des

proc´e-dures. La premi`ere montre comment les proc´edures sont cr´e´ees, et ajout´ees dans

le store.

proc{x X1. . . Xn}Send skip

σx=⊥ σ∧x=ξ∧ξ:proc{$X1. . . Xn}Send ^avec ξfresh

Cette r`egle s’assure quexne poss`ede aucune valeur, puis cr´ee un nouveau nom

ξ, et associex`aξetξ`a la proc´edure fraichement cr´e´ee. La seconde r`egle permet

deremplacer une proc´edure par une nouvelle. Cette r`egle est un rajout fait `a

Oz, pour prendre en compte des op´erations int´eressantes, comme l’h´eritage des

objets. Ce remplacement ne peut se faire que sous deux conditions : il faut que

la nouvelle proc´edure ait le mˆeme nombre d’argument que l’originale, et que

l’originale n’ait pas de r´ef´erence vers des variables ext´erieures (signal´e par la

contraintestrict(ξ)). Ces variables pourraient en effet constituer des effets de

bords qui ne seraient plus assur´es, et qui pourraient ainsi compromettrent le

bon fonctionnement de l’int´egralit´e du programme.

proc{x X1. . . Xn}S⁰end skip

σ∧ξ:proc{$X1. . . Xn}Send σ∧ξ:proc{$X1. . . Xn}S⁰end

si σx=ξ∧strict(ξ)

Finalement, l’utilisation d’une proc´edure se fait classiquement par l’application

de ses arguments, comme d´ecrit dans la r`egle qui suit :

{x x1. . . xn} S{x_i

/X_i}

σx=ξ∧ξ:proc{$X1. . . Xn}Send σ

Les r`egles pour les exceptions. Les exceptions sont g´er´ees par un ensemble

de cinq r`egles montrant la s´emantique du bloctry...catchet de la commande

raise. La premi`ere r`egle g`ere l’ex´ecution normale d’un bloc try... catch : le

codeS1 est ex´ecut´e normalement, tout en gardant la gardecatchau cas o`u un

probl‘eme surviendrait.

try S1catch X then S2end S1 hcatch X then S2endi

σ σ

Dans le cas o`u aucune exception n’a ´et´e lev´ee durant l’ex´ecution deS1, la garde

est simplement effac´ee :

catch Xthen S2end skip

σ σ

Par contre, supposons qu’une exception soit lev´ee : l’ex´ecution deS1 est alors

stopp´ee, et la garde est appel´ee pour traiter l’erreur. Cela est pris en compte

par les deux r`egles suivantes : la premi`ere termine l’ex´ecution deS1 en passant

toute les instructions qui ne sont pas des gardes.

ξhraise xend hS Tii ξhraise xend Ti

σ σ ^{si S}6≡catch . . .end

Une fois que la garde est trouv´ee le traitement de l’erreur se fait de la mˆeme

fa¸con que dans les autres langages :

Dans le document Composants et Typage (Page 133-149)