Le langage de spécification

Le cœur de Jakarta est constitu´e par un langage de sp´ecification (JSL pour Jakarta Specification Language) d´ecrivant les machines virtuelles dans un style math´ematique neutre. JSL est un langage `a types polymorphes dont l’ex´ecution est bas´ee sur la r´e´ecriture de termes [4, 23]. Ce langage se veut relativement simple afin de faciliter au maximum le lien avec les assistants de preuves ou les langages de programmation.

Les expressions Les expressions du langages JSL sont des termes du pre-mier ordre construits `a partir de variables et de symboles de constantes.

Ces derniers sont ou bien des symboles de constructeur, introduits par une d´eclaration de type de donn´ees, ou bien des symboles introduits par une d´efinition de fonction. JSL propose ´egalement une syntaxe concr`ete pour les enregistrements (record), cependant ceux-l`a sont traduits, comme le fait Coq, en un type inductif `a un seul constructeur et n’apparaissent alors pas dans les expressions du langage.

De mani`ere formelle, les expressions sont d´efinies comme suit :

D´efinition 1 (Expressions) Soient C un ensemble de symboles de constructeurs, D un ensemble de symboles de fonctions et V un ensemble de variables, alors l’ensemble E des expressions JSL est donn´e par la syn-taxe suivante :

E::=V | C E | D~ E~

o`u il est requis que les arit´es des ´el´ements de C et D soient respect´ees.

Les règles Les fonctions sont repr´esent´ees en Jakarta par l’interm´ediaire de r`egles de r´e´ecriture. Dans le cadre de l’abstraction et par rapport la repr´esentation des langages fonctionnels avec filtrage de motifs, cela pr´esente les avantages suivants :

– disposer directement de toutes les valeurs pouvant ˆetre prises par une fonction suivant les filtrages r´ealis´es, pour ˆetre alors en mesure de travailler ind´ependamment sur chacune d’entre elles ;

– obtenir plus de souplesse dans le structure des fonctions manipul´ees autorisant ainsi par exemple l’´ecriture de fonctions non-d´eterministes.

N´eanmoins, la traduction vers et depuis un langage `a filtrage de motifs reste pr´esente, en vue de la r´eutilisation des formalisations existantes.

Le lien avec le filtrage de motifs est rendu encore plus fort par les condi-tions de construction des r`egles de r´e´ecriture et la r´eutilisation de la notion de motif.

D´efinition 2 (Motifs) L’ensembleP des motifs est le sous-ensemble de E d´efini par la syntaxe :

P ::=V | C P~

o`u dans la seconde partie, les motifs doivent avoir un ensemble de variables disjointes.

Ces motifs sont r´eutilis´es dans les membres droits des r`egles de r´e´ecriture,

`

a la mani`ere du filtrage.

D´efinition 3 (R`egles de r´e´ecriture) Les r`egles de r´e´ecriture des fonc-tions du langage JSL sont de la forme :

l1 r1, . . . , lnrn⇒g→d o`u :

– r~_i ∈ P,~l_i,g,d∈ E, et g=f ~x (avec~x∈ V) sont deux `a deux distincts ; – var(lk)⊆var(g)∪var(r1)∪ . . . ∪var(rk−1)etvar(d)⊆var(g)∪var(~r_i);

– var(rk)∩var(g) =∅ etvar(rj)∩var(rk) =∅ sij6=k.

Ces contraintes rendent ainsi la liaison avec le filtrage de motifs ´evidente, par exemple, les r`egles suivantes :

lN il ⇒ (is empty l)→T rue l(Cons el tl) ⇒ (is empty l)→F alse

correspondent sous forme arborescente aux deux branches de la fonction ML suivante :

let is_empty l = match l with []→True | el::tl→False

Les types Par dessus le langage de sp´ecification pr´ec´edemment d´ecrit, vient se greffer un syst`eme de types, cl´e de la conduite de la g´en´eration d’abstrac-tion.

D´efinition 4 (Types) Soient les ensembles V_T de variables de type, T_d de symboles de types de donn´ees, T_a de symboles de types abstraits et T_s de symboles de types synonymes, alors l’ensemble T des types JSL est donn´e par la syntaxe suivante :

T ::=V_T | T_d T^∗ | T_a T^∗ | T_s T^∗

o`u il est requis que les arit´es des ´el´ements de T_d, T_a et T_s soient respect´ees.

Aux symboles de constructeurs ou de fonctions sont associ´es des sch´emas de types, c’est-`a-dire des expressions closes de la forme :

∀α₁. . . α_m. σ₁→. . .→σ_n→τ o`u α₁, . . . ,α_m ∈ V_T et σ₁, . . . ,σ_n,τ ∈ T.

On notera alorsE_T l’ensemble des expressions de type, constitu´e de l’en-semble des types et des sch´emas de type.

Le type valu des valeurs de la machine virtuelle d´efensive s’´ecrit par exemple en Jakarta sous la forme :

data valu =

VPrim valu_prim | VRef valu_ref and

data valu_ref = VRef_null |

VRef_array type0 heap_idx |

VRef_instance cap_class_idx heap_idx | VRef_interface cap_interf_idx heap_idx.

De mani`ere usuelle, le type des expressions est v´erifi´e (par un v´erificateur de type d´ecrit dans [92]) relativement `a un contexte qui associe un type `a chaque variable. En raison des synonymes de type, la v´erification de type est faite modulo la relation sur ces synonymes de type.

Les fonctions Il est maintenant possible de d´efinir les fonctions du langage JSL :

D´efinition 5 (Fonctions) Une fonction JSL f est d´efinie par la donn´ee de son type f: T₁ →...→T_m →U et d’un ensemble de r`egles de r´e´ecriture l1 r1, . . . , lnrn⇒g→ddont le symbole de tˆete de g estf.

La fonction IF_ACMP_COND de la page 58 est traduite en Jakarta sous la forme suivante :

function iF_ACMP_COND :

opcmp→bytecode_idx→jcvm_state→returned_state :=

<iF ACMP COND rule 1>

(stack_f state)→Nil

⇒(iF_ACMP_COND oper branch state)→ (abortCode State_error state);

<iF ACMP COND rule 2>

(stack_f state)→(Cons h lf), (head (opstack h))→(Value v2),

(head (tail (opstack h)))→(Value v1), v1→(VPrim v)

⇒(iF_ACMP_COND oper branch state)→ (abortCode Type_error state);

<iF ACMP COND rule 3>

(stack_f state)→(Cons h lf), (head (opstack h))→(Value v2),

(head (tail (opstack h)))→(Value v1), v1→(VRef vx),

v2→(VPrim v)

⇒(iF_ACMP_COND oper branch state)→ (abortCode Type_error state);

<iF ACMP COND rule 4>

(stack_f state)→(Cons h lf), (head (opstack h))→(Value v2),

(head (tail (opstack h)))→(Value v1), v1→(VRef vx),

v2→(VRef vy)

⇒(iF_ACMP_COND oper branch state)→ (update_frame (res_pc2_nat

(res_acompare2 oper (vr2hi vx) (vr2hi vy)) branch h) state);

<iF ACMP COND rule 5>

(stack_f state)→(Cons h lf), (head (opstack h))→(Value v2), (head (tail (opstack h)))→Error

⇒(iF_ACMP_COND oper branch state)→ (abortCode Opstack_error state);

<iF ACMP COND rule 6>

(stack_f state)→(Cons h lf), (head (opstack h))→Error

⇒(iF_ACMP_COND oper branch state)→ (abortCode Opstack_error state) .

On y observe clairement les diff´erents chemins d’ex´ecution de la fonction.

Il est possible de d´efinir un mod`ele d’ex´ecution sur ces fonctions. En reprenant les notations de [20] :

D´efinition 6 (Mod`ele d’ex´ecution) SoitR un ensemble de r`egles de r´

e-´ecriture. Une expression s se r´e´ecrit en t par R, que l’on note s→_R t, s’il existe une r`egle r deR

l₁r₁, . . . , l_nr_n⇒g→d

une positionp dans set une substitution θ des variables de R telles que – s|_p =θg et t=s[p←θd];

– pour 1≤i≤n, θli →^∗_Rθri;

o`u →^∗_R est la clˆoture r´eflexive et transitive de→_R.

On notera qu’aucune contrainte n’assure l’exhaustivit´e ou la confluence des r`egles de r´e´ecriture d´efinissant une fonction. On se permet ainsi de d´efinir dans le mod`ele JSL des fonctions partielles ou non-d´eterministes.