ARIANE-G5 : Les langages spécialisés TRACOMPL et EXPANS.

Transcription

Documentation du système Ariane-G5
Document LG5.SCRIPT
ARIANE-G5 :
Les langages spécialisés
TRACOMPL et EXPANS.
Décorations et règles lexicales
Auteur : Pierre Guillaume
Introduction. 1
LES LANGAGES SPECIALISES. 1
Partie géométrique et partie algébrique. 2
Les différents LSPL d'ARIANE-G5. 2
LES STRUCTURES DE DECORATION. 3
Déclarations de variables: aspects syntaxiques. 3
Variables élémentaires. 3
Variables générales. 4
Variables générales préétablies. 4
Déclarations de variables: aspects sémantiques. 6
LES CONTEXTES DANS LES DIFFERENTS LSPL. 8
Contextes du LSPL ATEF. 9
Contextes du LSPL SYGMOR. 10
Contextes des LSPL REFORM et TRACOMPL. 10
Contextes du LSPL EXPANS en mode monolingue et bilingue. 11
LES OPERATIONS SUR LES STRUCTURES DE DECORATIONS MONOLINGUE ET BILINGUE. 12
Expressions de conditions. 12
Expressions d'affectations. 13
Réseaux d'affectations conditionnelles. 13
LES PROCEDURES. 13
BASE COMMUNE AUX LSPL TRACOMPL ET EXPANS (MONOLINGUE ET BILINGUE). 14
Déclarations de variables. 14
Procédures. 15
Réseaux d'affectations conditionnelles. 21
LE LSPL TRACOMPL. 22
Principes généraux. 22
Composante algorithmique. 22
Détail des données linguistiques. 22
LE LSPL EXPANS EN MODE MONOLINGUE ET BILINGUE. 25
Principes généraux. 25
Composante algorithmique. 26
Détail des données linguistiques. 27
Déclarations de variables. 28
Fichiers des formats sources et cibles. 30
Définitions de procédures. 30
Dictionnaires généraux (de 1 à 7). 33
Dictionnaire zéro. 37
a) Les triplets d'action par défaut. 37
b) Le triplet prise en compte de la racine multidictionnaire. 37
c) Le triplet associé à "UL0". 37
CARTES SYNTAXIQUES. 38
Syntaxe. 38
Graphe de dépendances des unités syntaxiques. 38
Commentaires. 38
Syntaxe de la partie déclarations de variables. 38
I.1 - <DECVAR> : Déclaration des variables. 38
I.2 - <ELDEX> : Elément de déclaration des variables. 39
I.3 - <DICT> : déclaration de la variable dictionnaires (phase ATEF). 39
I.4 - <VAVEX> : Partie droite de l'élément de déclarations de variables. 39
Syntaxe des définitions de procédures. 39
II.1 - <FIPROC> : Fichier des déclarations de procédures. 39
II.2 - <DPROC> : Définition des procédures. 39
II.3 - <PROCET> : Définition des procédures d'étiquette. 39
II.4 - <LDPROCET> : Liste de définition des procédures d'étiquette. 39
II.5 - <DPCIS> : Définition de procédures de conditions intersommets. 39
II.6 - <DPCP> : Définition de procédure de condition propre. 40
II.7 - <DPAF> : Définition de procédure d'affectations. 40
II.8 - <LDPRCA> : Liste de définition de procédures RCA. 40
II.9 - <DPRCA> : Définition de procédure réseau. 40
Syntaxe des dictionnaires EXPANS. 40
III.1 - <ARTDIEX0> : Article pour le dictionnaire numéro zéro (huit triplets de rattrapage). 40
III.2 - <ARTDIUL0> : Article associé à UL0. 40
III.3 - <ARTDIRAC> : Article pour calcul de l'étiquette de la racine multidictionnaire. 40
III.4 - <ARTDIEX> : Article dictionnaire (forme générale). 40
III.5 - <ARBOR> : Arborescence transformée. 41
III.6 - <AFUL> : Expression d'affectation d'UL chaîne. 41
Syntaxe de la partie commune. 41
IV.1 - <RESAS1> : Réseau d'affectations conditionnelles (forme 1). 41
IV.2 - <RESAS2> : Réseau d'affectations conditionnelles (forme 2). 41
IV.3 - <ACOND> : Partie condition en réseau. 41
IV.4 - <AFREZ> : Partie affectation en réseau. 41
IV.5 - <APRORCA> : Appel de procédure réseau. 41
IV.6 - <AFGL> : Affectation globale. 41
IV.7 - <EXPC> : Complément d'affectations. 42
IV.8 - <APROCAF> : Appel de procédure d'affectation. 42
IV.9 - <AFREG> : Affectation. 42
IV.10 - <AFECT> : Expression d'affectation. 42
IV.11 - <APROCIS> : Appel de procédure de condition. 43
iv.12 - <EXBOOL> : Expression booléenne. 43
IV.13 - <TSTET> : Niveau ET. 43
IV.14 - <EXBOOL2> : Niveau N. 43
IV.15 - <RELAT> : Relation. 43
2
IV.16 - <TSUNI> : Niveau U. 43
IV.17 - <TSINT> : Niveau I. 43
IV.18 - <EL2> : Elément 2. 43
IV.19 - <OPER> : Opérande. 43
CONCLUSION. 44
DOCUMENTS REFERENCES. 44
3
ARIANE-G5 Les langages spécialisés
TRACOMPL et EXPANS.
Décorations et règles lexicales
Introduction.
Ce document est une nouvelle édition du précédent document (5) où on a revu l'emploi de certains termes. En particulier,
plutôt que d'adopter deux noms distincts pour le nouveau LSPL (Langage Spécialisé de Programmation Linguistique) du
générateur ARIANE-G5, qui succède à ARIANE-78, on a préféré couvrir par le nom unique d'EXPANS les deux
réalisations désignées par EXPANS et TRANSFER, qui apparaissent comme des variétés d'un même LSPL. L'introduction
de ce LSPL ne constitue qu'un aspect de la refonte profonde à laquelle a été soumis le système ARIANE, mais comme
beaucoup de ces aspects restent internes au système, c'est sans doute celui-là qui est le plus sensible pour l'utilisateur.
Une première partie développe des considérations générales sur l'utilisation des variables et les structures de décorations qui
prennent une importance plus grande avec ce nouveau LSPL (chapitres I à V). La seconde partie est plus précisément
consacrée à présenter les fonctionnalités et le langage associés à ces nouveaux LSPL, et elle servira de référence pour leur
utilisation (chapitres VI à IX). L'utilisateur pourra se reporter aux cartes syntaxiques reprises de (3), lorsqu'il désirera
approfondir certains points relatifs à la codification des données de ses applications.
La référence pour l'ensemble des LSPL du système ARIANE-G5, reste le DSE-1 (1). Ce document en précise certains
points, en modifie d'autres (en particulier le LSPL TRANSF), mais le complète surtout par ce qui est propre au LSPL
EXPANS dans ses modes de fonctionnement monolingue et bilingue ainsi qu'au LSPL TRACOMPL.
LES LANGAGES SPECIALISES.
ARIANE-G5 est un système conçu en vue des applications de traduction automatique, à partir, et vers, des textes rédigés en
diverses langues naturelles. C'est un système dérivé d'ARIANE-78 (1), et comme lui, organisé autour d'un certain nombre
de LSPL. Un "langage spécialisé" pour le "programmeur linguiste" offre des structures de données adaptées (arbres décorés)
et des mécanismes sous-jacents très puissants (systèmes de réécriture, récursivité, non-déterminisme, reconnaissance de
formes, modularité, décidabilité ...).
Un processus de traduction, en ARIANE-G5, se décompose en une suite de trois étapes (analyse, transfert et génération),
constituées elles-mêmes par une suite de différentes phases de traitements. Chacune est relative à l'emploi d'un LSPL précis.
La forme générale des données traitées est celle de l'arborescence décorée. Si les textes apparaissent comme structurés en
chaîne de mots, pour ARIANE-G5, ce sont en fait des arborescences dont les nœuds sont décorés par des segments (suite de
mots encadrés par des marquants) pour les nœuds terminaux, ou des suites de segments, pour les nœuds non terminaux
(prise en compte de marquants hiérarchisés).
En ARIANE-G5, (comme en ARIANE-78), tous les LSPL sont du type transducteur. Ces transducteurs font intervenir des
automates généraux dans la classe du modèle associé sous-jacent. Ils imposent la définition d'une application précise, à
l'aide de règles de réécriture explicites (ou de données plus spécialisées), écrites suivant la syntaxe du LSPL considéré. Pour
l'utilisateur développant une application, on parle des "données linguistiques" de cette application (ou "linguiciel" de cette
application, par analogie avec le mot "logiciel").
Partie géométrique et partie algébrique.
Pour tous les LSPL, l'utilisateur a une perception à deux niveaux des données qu'il est amené à manipuler:
- un niveau "géométrique", lié à la nature des structures que le LSPL traite, et donc fonction du LSPL;
- un niveau "algébrique" relativement constant pour tous les LSPL et lié aux valeurs de décorations associées à
chacun des éléments de la partie géométrique.
Par exemple: une solution pour le mot précédent ou le mot courant en ATEF, le nœud frère gauche d'un nœud donné en
ROBRA, sont des notions géométriques, alors que le test de configuration de valeurs précises sur ces éléments relève du
niveau algébrique.
Il appartient d'ailleurs à l'utilisateur de définir, pour ses données, l'organisation qu'il estime la plus adaptée, par répartition
des informations entre ces deux parties géométrique et algébrique, en tenant compte des propriétés et contraintes propres à
chacune de ces composantes (problème de représentation).
La première partie de ce document est consacrée à une présentation détaillée de la partie algébrique, dont beaucoup
d'aspects sont communs aux différents LSPL d'ARIANE-G5. Pour résumer, on peut dire que cette partie recouvre l'emploi
de ce que l'on appelle "variables" et "valeurs". Ces variables et valeurs se constituent en unités complexes ("décorations").
Leur emploi est régi par une combinatoire définie par des règles précises. Intégrant les métalangages des différents LSPL,
les compilateurs ont, en particulier, pour rôle de s'assurer que les règles d'emploi sont respectées.
Les constituants des différents métalangages associés à la partie algébrique sont formés par:
- une composante déclarative: "déclarations de variables";
- des composantes opératoires (expressions de calcul sur les variables), qui recouvrent:
- les expressions d'affectations,
- les expressions de conditions,
- leur prolongement: les réseaux d'affectations conditionnelles (RCA).
Les différents LSPL d'ARIANE-G5.
Il apparaît indispensable de préciser ici brièvement, quels sont les différents LSPL qui constituent ARIANE-G5.
- ATEF est un transducteur chaîne->arbre (modèle d'états finis non déterministe) destiné à l'analyse
morphologique des mots d'un texte source,
- SYGMOR est un transducteur arbre->chaîne (modèle d'états finis déterministe) destiné à la génération
morphologique des mots d'un texte cible,
- ROBRA est un transducteur général arbre->arbre utilisé dans les phases d'analyse syntaxo-sémantique, de
transfert structural et de génération syntaxique,
-&$RB.REFORM est un transducteur arbre->arbre, sans données linguistiques propres, réalisant le passage,
pour un même arbre, d'une structure de décoration source, vers une structure de décoration cible,
- TRACOMPL est un transducteur arbre->arbre réalisant les fonctions de REFORM, auxquelles il ajoute la
prise en compte d'un calcul complémentaire des valeurs de la décoration cible,
- EXPANS correspond à un transducteur arbre->arbre. Ce même modèle comporte deux types de
fonctionnement: le premier en mode EXPANS-1 (ou mode monolingue), le second en mode EXPANS-2 (ou
2
mode bilingue). EXPANS en mode bilingue apparaît comme une extension de l'ancien LSPL TRANSF
d'ARIANE-78, et comme lui, réalise des transformations à base lexicale.
Les LSPL ATEF, SYGMOR, ROBRA et REFORM existaient déjà en ARIANE-78. Les LSPL TRACOMPL ainsi
qu'EXPANS sous ses formes monolingue ou bilingue sont propres à ARIANE-G5, la dernière forme se substituant à
TRANSF. ATEF, SYGMOR et ROBRA ont été étendus pour ARIANE-G5.
LES STRUCTURES DE DECORATION.
A chaque élément de la structure géométrique est associée une certaine valeur complexe. Cette valeur décrit, sous une forme
structurée, des informations de provenances diverses, en particulier celles qui sont obtenues à partir des "déclarations de
variables". Dans ces déclarations de variables, figurent, en particulier, des variables "élémentaires" et les valeurs associées.
Si, à une variable élémentaire, peut correspondre, au plus, une valeur associée, cette variable est dite de nature "exclusive"
ou arithmétique (valeurs d'entiers relatifs). S'il peut lui correspondre une partie de l'ensemble des valeurs associées, cette
variable est dite de nature "non exclusive". L'utilisateur peut explicitement structurer ses variables sous forme arborescente
par emploi de "variables générales". De toute façon, l'introduction de variables générales prédéfinies, induit une telle
structure arborescente sur l'ensemble des variables et valeurs déclarées.
La structure de décoration intègre cette structure arborescente, elle est complétée par:
- la forme (ou suite de lettres codifiant un mot du texte), qui a donc pour valeur une chaîne de caractères, mais
pour laquelle on ne trouve aucun désignateur associé dans aucun des différents métalangages,
- la valeur d'Unité Lexicale "(UL)", c'est-à-dire une valeur servant de référence à une famille d'éléments du
lexique. Elle possède également une valeur de chaîne de caractères. Cette variable, que l'on peut considérer de
nature "exclusive", est à ensemble de valeurs "ouvert" (les valeurs associées ne sont pas explicitement
déclarées). Dans les différents métalangages, on lui associe le désignateur préétabli: "UL".
Ainsi complétée par la forme et l'UL, la structure de décoration peut être vue comme une structure arborescente générique,
dont les réalisations (valeurs) possibles constituent les "valeurs de décorations" associées aux éléments de la structure
géométrique.
Si l'on fait abstraction des limites d'implémentation portant sur les longueurs des chaînes, l'ensemble des valeurs réalisables
est isomorphe à N (dénombrable), si l'on en tient compte, il est isomorphe à un segment de N (fini).
On notera qu'ARIANE-G5 ne travaille jamais (de façon interne) sur la structure de décoration explicitée, mais sur des
vecteurs représentatifs des valeurs de variables élémentaires. C'est au niveau des compilateurs des métalangages, qu'est
prise en charge cette structuration (en particulier pour l'emploi des variables générales dans les expressions). La sortie en
clair des valeurs de décorations, se limite aux variables élémentaires et à leurs valeurs associées. La forme utilisée est donc
réductible à une arborescence à trois niveaux (la représentation de la racine reste implicite), qui peut être considérée comme
une "représentation canonique" de la valeur de décoration.
On notera également que, dans le système ARIANE, le mot "format" ("template" en anglais) dénote une donnée linguistique
homogène à une valeur de décoration, et référençable à partir de composantes telles que grammaires, dictionnaires, etc ...
Déclarations de variables: aspects syntaxiques.
Variables élémentaires.
Une variable élémentaire est déclarée par association de son nom, à une liste de noms déterminant l'ensemble des valeurs
qu'elle peut prendre. Selon son emplacement dans le fichier des déclarations de variables (emploi des séparateurs "-EXC-",
"-NEX-" et "-ARITH-"), cette variable sera de nature:
3
- exclusive: la valeur effective est, au plus, une des valeurs associées,
Exemple:
VEX1 == ( 1 , 2 , 3 ).
Si "n" valeurs sont associées, la variable est dite de "cardinal n".
- non exclusive: les valeurs effectives sont prises dans l'ensemble des parties de l'ensemble des valeurs
associées,
Exemple:
VNEX1 == ( A , B , C , D ).
Si "n" valeurs sont associées, la variable est dite de "cardinal n".
- arithmétique: la liste des noms de valeurs est réduite à un unique entier "p" ( >0 ). La variable peut prendre
ses valeurs dans l'intervalle:
-2**(n+1) <= x <= 2**(n+1)-1, avec 2**n <= p < 2**n+1.
Exemple:
VAR1 == (17).
VAR1 peut prendre ses valeurs de -32 à +31. La variable est dite de "cardinal n".
Variables générales.
Si on associe à une variable, non plus une simple liste de noms, mais une liste d'arborescences, la variable sera considérée
comme "générale". Le seront également, les variables associées aux noms figurant dans les arborescences qui ne sont pas
des feuilles, ou leur père immédiat (qui sont considérées comme des valeurs et variables élémentaires). On notera qu'un
sommet de l'arborescence domine, soit une suite de feuilles, soit une suite de non-feuilles, mais jamais de suite mixte (la
récursivité se fait entre variables et non entre variables-valeurs (VAVEX (I.4).
Exemple:
VEX1 == ( VEX1A (1,2), VEX1B ( VEX1C (A,B), VEX1D (C,D))).
Les variables générales sont: VEX1, VEX1B.
Les variables élémentaires sont: VEX1A, VEX1C et VEX1D.
D'après ce qui vient d'être dit:
VEX1
==
( 1 , VEX1A (A,B) ).
est une déclaration illicite.
On considère donc, en ARIANE-G5, qu'une variable générale ne peut se voir associer des valeurs en propre.
Variables générales préétablies.
Une déclaration de variable générale explicite est interne à l'une des listes de déclarations correspondant à l'un des trois
types: exclusif, non exclusif ou arithmétique. Le compilateur complète la structure arborescente des déclarations, par
l'introduction des variables générales recouvrant (s'ils sont non vides) les ensembles des:
- variables exclusives ("VARE<phi>"),
- variables non exclusives ("VARN<phi>"),
- variables arithmétiques ("VARA<phi>").
4
"Phi" est indicatif lié à la phase.
Chacune de ces variables générales se voit attribuer le type correspondant.
Une autre variable générale recouvre les trois précédentes (son type est exclusif, c'est-à-dire le type le plus contraint). Elle
correspond à l'ensemble des variables d'un jeu pour une phase ("VAR<phi>").
Enfin la variable "VAR" correspond à la totalité de la structure de décoration (forme et UL non incluses). Elle est également
de type exclusif.
Il est possible d'intervenir sur les noms attribués à ces variables générales préétablies, par utilisation des codes <alpha>,
<bêta> et <gamma> (voir (I.1) ).
Ce qui précède correspond à des règles générales concernant les déclarations de variables. Pour certains LSPL, il existe des
restrictions. C'est ainsi que:
- ATEF - n'accepte pas l'emploi des variables arithmétiques,
- n'accepte pas l'emploi des variables générales (sauf prédéfinies),
- impose la déclaration d'une variable "DICT" (stratégique) qui ne fait pas partie de la structure de
décoration (voir (I.3) ),
- impose de déclarer deux jeux de variables dits "morphologiques" et "syntaxiques", pour une même
structure de décoration.
De même: - SYGMOR - impose des noms de variables et de valeurs tous distincts deux à deux,
- n'accepte pas les variables arithmétiques.
On remarquera que chaque phase d'ARIANE comporte ses propres déclarations de variables. Cela veut dire, qu'au cours
d'un traitement, la structure de décoration évolue lorsque l'on progresse d'une phase à la suivante. Il y a alors passage des
valeurs des variables déclarées comme communes. En ARIANE-78, pour toute variable (élémentaire ou générale) à laquelle
est associée, dans les déclarations, une liste de valeurs réduite à "*", il y a introduction automatique de la sous-structure de
déclaration de la phase précédente correspondant à la variable de même nom, et les valeurs correspondantes sont
considérées comme communes. Ce mécanisme a, en pratique, l'inconvénient de propager les modifications faites sur les
variables, entre des phases successives et donc, d'impliquer des "recompilations" qui peuvent être lourdes. Toujours en
ARIANE-78, au niveau de la génération syntaxique, phase vers laquelle peuvent converger différentes analyses, et
transferts, on doit utiliser une déclaration complète des variables et de leurs valeurs et noter, par l'emploi du préfixe "$",
devant le nom de la variable, le fait que ses valeurs proviennent d'une phase précédente. On préserve ainsi l'indépendance
des compilations entre phases. C'est l'emploi de cette convention qui a été généralisé en ARIANE-G5 (2). Le passage
effectif de la structure de décoration d'une phase, à la structure de décoration de la phase suivante, est le rôle du LSPL
"REFORM".
ARIANE-G5 généralise aussi certaines propriétés du LSPL TRANSF d'ARIANE-78, en particulier, le fait qu'un LSPL
puisse fonctionner avec deux structures de décorations simultanées, associées aux données source et cible. En effet, dans le
LSPL TRANSF (transfert lexical), qui est un modèle de création (structures de données source et cible disjointes), la
structure source (arborescence) est considérée comme décorée sur la structure de déclaration de la phase précédente, la
structure cible (également arborescence) est, elle, décorée sur les déclarations courantes.
5
Cette propriété se retrouve dans le nouveau LSPL EXPANS d'ARIANE-G5, mais comme l'indépendance des déclarations
de variables entre phases était requise, on a été amené à expliciter les deux jeux de déclarations dans une même composante
de déclarations des variables (2). Il en résulte un élargissement des conventions.
Un nom de variable préfixé par "$":
- correspond à une variable dont les valeurs proviennent de la variable de même nom figurant dans la phase
précédente (les types et cardinalités doivent coïncider). Si la phase est à deux jeux de décorations (biétiquetée),
on considère que la variable appartient aux deux jeux.
Un nom de variable préfixé par "$$":
- figure dans une phase biétiquetée. On peut également l'utiliser en phase ROBRA où l'on trouve, en fait, la
suite des LSPL TRACOMPL et ROBRA. Les propriétés sont celles induites par l'emploi de "$", mais la
variable est associée uniquement au jeu de décoration source (jeu 1).
Un nom de variable non préfixé:
- la variable est considérée comme "créée" pour la phase. Il n'y a donc pas de recherche d'association avec une
variable de la phase précédente. Si la phase est biétiquetée, la variable est associée uniquement au jeu de
décoration cible (jeu 2).
Dans un même jeu de variables, les noms de valeurs de variables n'ont pas à être distincts entre variables élémentaires
différentes (le LSPL SYGMOR fait exception à cette règle). Ils doivent, bien évidemment, l'être à l'intérieur d'une même
variable élémentaire. Par contre, les noms de variables doivent être distincts deux à deux dans un même jeu. Cette contrainte
n'a pas à être vérifiée entre deux jeux d'une même déclaration, puisque, d'une part une variable $<nv> est considérée comme
étant une seule variable figurant dans deux jeux différents, d'autre part, <nv> et $$<nv> peuvent être les noms de deux
variables distinctes (sans relations entre elles), donc de types, et/ou de cardinal distincts.
On verra que cela conditionne certains aspects du métalangage relatif à l'écriture des expressions, dans le LSPL EXPANS.
Déclarations de variables: aspects sémantiques.
A la relation de préordre induite sur l'ensemble des variables d'un même jeu de décoration, par la structuration arborescente
des déclarations, se superpose, entre variables d'un même type, exclusif ou non exclusif, une relation induite par l'identité de
cardinal. Une correspondance (couplage) découlant d'une mise en correspondance biunivoque des valeurs associées à de
telles variables (la correspondance respecte l'ordre des déclarations des valeurs), permet de donner une interprétation à des
opérations telles que union, intersection de valeurs, ainsi qu'à des relations telles que égalité, etc ... De telles variables
compatibles sont donc acceptées comme opérandes compatibles à l'intérieur d'unités syntaxiques telles que affectations:
"<AFECT>" (IV.10), ou relations: "<RELAT>" (IV.15), qui composent les expressions.
Les opérations d'intersection, union et complémentation sont effectuées sur la partie commune aux deux opérandes figurant
en arguments de ces opérateurs.
Une telle correspondance existe également entre variables arithmétiques. Elle est alors systématique et indépendante des
cardinalités des variables. Dans une même expression arithmétique, les variables arithmétiques peuvent figurer sans
contraintes. Les opérations de l'arithmétique sont effectuées par cadrage à droite des opérandes et la troncature est
déterminée par l'opérande de plus faible cardinalité.
On verra qu'en fait, cette relation de compatibilité ne se limite pas à un seul jeu de décoration, mais a été étendue entre deux
jeux de variables.
Exemples:
--> déclarations des variables:
6
V5
V1
==
==
( A , B , C ).
( V2 (1,2,3) , V3 (A,B,C,D) , V4 (1,2,3) ).
V2, V4 et V5 sont des variables compatibles.
--> expression licite faisant intervenir des sous-variables:
V1(X) -I- ( ( V2(Y) -I- (1-U-3) ) -U!
!
( V3(Z) -I- (A-U-D) ) ) -NE- V10.
!
!
!
+-------------+
!
!
!
+-------------------------+
--> interprétation:
Si V1(X) = V2(1,2),V3(A,B,C),V4(1,3),
et V2(Y) = V2(1,2,3),
et V3(Z) = V3(A,B,C),
alors:
V2(Y) -I- (1-U-3) = V2(1,3),
V3(Z) -I- (A-U-D) = V3(A),
(V2(Y) -I- (1-U-3)) -U- (V3(Z) -I- (A-U-D)) = V2(1,3),V3(A),
et le résultat est:
V2(1),V3(A),V4(1,3) ^= V10.
--> expression licite faisant intervenir des variables compatibles:
V1(X) -I- ( V2(Y) -I- V5(Z) -I- (A-U-B) ) -E- V10.
!
! !
!
+-----------+ +-------+
--> interprétation:
Si l'on a les mêmes hypothèses que précédemment, et de plus:
7
V5(Z) = V5(A,C),
alors:
V5(Z) -I- (A-U-B) = V5(A),
V2(Y) -I- V5(Z) -I- (A-U-B) = V2(1),
et le résultat est:
V2(1) ^= V10.
LES CONTEXTES DANS LES DIFFERENTS LSPL.
On a vu que les LSPSL constituant le système ARIANE pouvaient être classés en modèles: chaîne->arbre, arbre->arbre et
arbre->chaîne, selon la nature des structures de données qu'ils traitent. On peut également les classer en modèles de création
(tous les LSPL, à l'exclusion de ROBRA), à structures de données source et cible disjointes, et modèle de transformation (le
LSPL ROBRA), où structures objets sources et cibles, constituent en fait une unique structure.
Tous ces LSPL fonctionnent comme des transducteurs, une étape élémentaire du fonctionnement étant l'application d'une,
ou éventuellement plusieurs, règles de transformation reconnues comme applicables. Ce fonctionnement est "supervisé" par
un "contrôle" dont certains éléments peuvent être explicités. Par exemple, la progression sur les mots d'entrée en ATEF n'est
jamais directement explicitée, par contre les références aux différents dictionnaires et la fin de recherche des solutions
associées au mot courant peuvent l'être. En ROBRA, on ne peut expliciter des stratégies particulières de prise en compte des
"marques de règles" associées à la structure objet, elles doivent toutes se situer dans le cadre très précis des contrôles
préétablis (mode libre/gardé, ponctuel/dessous ... ), par contre, on explicite le traitement sur une sous-structure (appel
récursif) et les conditions de transitions dans le graphe des liens entre grammaires élémentaires (contrôle du fonctionnement
non déterministe).
Ce qui nous concerne ici, c'est essentiellement le processus d'application d'une ou plusieurs règles valides. On considérera
que l'on travaille sur une structure objet source (qui peut être une sous-structure d'une structure plus globale), et que le
résultat sera une structure objet cible. Dans un modèle de création, cette structure objet cible complétera la structure objet
cible courante, dans un modèle de transformation, elle remplacera la structure objet source. La recherche des règles
applicables sur la structure objet source sera, sous sa forme la plus générale, réalisée par "pattern-matching", conduisant à
une famille de sous-structures (occurrences de règles) dont chacune sera transformée par application d'une règle
(transformations parallèles). L'application de la règle fait intervenir les éléments de la structure source constituant
l'occurrence, de deux façons:
1) ces éléments doivent entretenir certaines relations pour que la règle soit applicable,
2) ils seront des sources d'informations pour le calcul de la structure objet cible.
Pour la transformation, ces éléments constitueront le "contexte gauche" de la règle. La structure objet cible décrite en partie
droite de la règle, verra ses éléments constituer le "contexte droit" de la règle. Les deux contextes réunis, constitueront le
8
"contexte global" de la règle. Ce contexte peut lui-même être augmenté par des données linguistiques référençables,
constituant le "contexte étendu" de la règle.
Contextes du LSPL ATEF.
Le LSPL ATEF a pour but, partant de la suite des mots ("formes") qui constitue le texte d'entrée soumis à l'analyse
morphologique, de fournir pour chacun des mots, et ce, par un mécanisme de "segmentation" faisant intervenir dictionnaires
et grammaire, l'ensemble des valeurs de décorations (solutions) que l'on peut lui associer. La recherche des segmentations
licites se fait par progression à partir d'une extrémité (gauche ou droite) de la forme, recherche dans les différents
dictionnaires des segments de la forme ("morphes") candidats possibles à chacun des stades de la segmentation, et leur prise
en compte de façon non déterministe.
L'automate progresse sur la suite des mots du texte d'entrée par déplacement d'une fenêtre recouvrant une suite de six mots
successifs qui constituent le contexte source de l'automate. Le mot en cours de segmentation est le "mot courant" "(C)".
L'automate construit en parallèle une structure de sortie qui se présente comme un graphe reflétant la suite des occurrences
d'entrée et des solutions qui leur sont associées, accompagnées des chaînages acceptables entre ces solutions. Le contexte
cible est une fenêtre sur la structure de sortie, qui progresse en parallèle avec le contexte source.
Une partie du contexte cible est non modifiable, elle est constituée par:
- les valeurs des solutions déjà associées aux occurrences précédentes ("(P1)", "(P2)", "(P3)" et "(P4)"),
- les valeurs extraites par SOL dans le début de la segmentation courante ("(PS1)", "(PS2)", ...),
- les valeurs des solutions déjà trouvées pour l'occurrence courante (d'ailleurs non accessibles),
Une partie est modifiable, elle est constituée par:
-la valeur d'étiquette en cours de calcul "(C)", accompagnée de la valeur de la chaîne restant à analyser
(référençable par "SCHAINE(A)" et transformable par "TCHAINE"),
- la valeur de décoration (unique) associée à l'occurrence suivante "(S)", qui deviendra la valeur initiale de
l'état courant lors de la segmentation de la forme suivante.
Ces contextes sont augmentés par une valeur de décoration provenant de l'entrée du dictionnaire activée (chaîne = morphe,
UL = valeur d'UL de l'entrée, les valeurs de variables sont introduites par les formats), cette valeur est dite "valeur
argument" et référencée par "(A)" (le morphe ne l'est pas).
En plus des valeurs de variables morphologiques, le format morphologique introduit un ensemble de règles (sousgrammaire), soumises chacune à des conditions d'application. Seront prises en compte, en parallèle, toutes les règles dont
les conditions d'application sont vérifiées à ce stade de la segmentation. L'application d'une règle constitue une progression
élémentaire de l'automate de segmentation. Les conditions d'application font intervenir: la valeur d'étiquette courante, la
valeur d'étiquette argument et les valeurs d'étiquette associées aux solutions précédentes, ainsi que la valeur de la forme
associée au suivant "(S)".
Chaque fois que l'on obtient une segmentation complète du mot courant, une solution représentant la valeur de l'état courant
lui est associée. Les chaînages associés sont le reflet des conditions d'applicabilité des règles faisant intervenir le contexte
associé aux "P1", "P2", "P3" et "P4".
Dans la pratique, ce contexte est élargi par la possibilité d'extraction de solutions en cours de segmentation (traitement des
mots composés et emploi de la fonction "-SOL-") référencées "PS1" ... "PS9".
Ce contexte est également étendu par un traitement intégrant plusieurs occurrences successives (traitement des tournures par
emploi de la fonction "TOURN", fonction "ELIT" et fonction "ELIM"). Il est réinitialisé par la fonction "-INIT-".
9
Le résultat de sortie du LSPL ATEF, sous forme d'arborescence décorée, est obtenu en prenant en compte de diverses
façons, les chaînages entre solutions (extraction en mode homophrase ou non homophrase).
.* emplacement schéma S1 (22 lignes).
Contextes du LSPL SYGMOR.
La structure de donnée source est l'arborescence décorée résultant de la phase de génération syntaxique qui précède. Le
contexte source est réduit à deux nœuds feuilles successifs de cette arborescence avec leurs décorations. Les valeurs de la
décoration courante sont référencées par "(C)", celles de la précédente par "(P)". Ce contexte est non modifiable. Le
contexte cible est constitué par deux chaînes: la dernière produite "(S)", et la chaîne courante "(T)".
Contextes des LSPL REFORM et TRACOMPL.
Le LSPL REFORM est utilisé, entre deux phases successives, pour passer d'un jeu de décoration au suivant. Il ne comporte
pas de données linguistiques qui lui soient associées en propre, mais utilise les déclarations de variables des phases
précédentes et suivantes.
De même, le LSPL TRACOMPL permet de passer d'un jeu de décorations à un autre, sur une même arborescence, mais, de
plus, il fait intervenir, pour le calcul des valeurs d'étiquettes cibles, un réseau d'affectations conditionnelles. Le fichier des
déclarations de variables consigne toutes les données linguistiques utilisées. C'est un modèle biétiqueté, le jeu de décoration
source est le jeu&$RB.1 des déclarations de variables, le jeu de décoration cible, le jeu&$RB.2.
Le contexte source est constitué par un unique sommet de l'arborescence source "(@S)", et le contexte cible, par une valeur
initiale "(çS)", dans le jeu d'étiquette cible et par la valeur courante "(S)", la seule qui soit modifiable.
10
Contextes du LSPL EXPANS en mode monolingue et bilingue.
Le rôle de ces contextes est d'obtenir à partir d'une arborescence source, au vu de données considérées comme uniquement
lexicales, une arborescence cible correspondante. Le contexte source est constitué par une fenêtre de quatre sommets dans
l'arborescence source:
- le sommet courant "(@S)", son père "(@P)", le frère gauche du courant "(@G)" et son frère droit "(@D)". Ces sommets
sont décorés sur le jeu d'étiquettes sources. Le contexte cible est constitué par l'arborescence de partie droite de l'entrée de
dictionnaire qui convient. Les valeurs de décorations sont prises sur le jeu de décorations cibles.
11
LES OPERATIONS SUR LES STRUCTURES DE DECORATIONS MONOLINGUE ET
BILINGUE.
Le métalangage d'un LSPL recouvre plusieurs composantes qui jouent des rôles complémentaires. Pour tous les LSPL, on
retrouve une composante liée aux déclarations de variables, et une autre correspondant aux définitions de formats (valeurs
de décorations associées aux données linguistiques). Ces composantes recouvrent des données de nature déclarative ou
statique. Viennent s'y ajouter les composantes relatives aux définitions de procédures, aux dictionnaires et grammaires, qui
sont propres à chaque LSPL (avec néanmoins des analogies profondes).
Une règle de grammaire décrit une transition conditionnelle de l'automate (le transducteur). On y trouve donc des éléments
dits "conditions d'applications" et des éléments liés à la transformation. Pour les parties de ces éléments traitant des valeurs
d'étiquettes, le formalisme correspondant est celui des "expressions de conditions" et "expressions d'affectations". Ces
expressions s'appliquent aux éléments du contexte. On considère que ce contexte se présente comme un ensemble de valeurs
de décorations. Le contexte source est celui qui est associé à la structure objet source, le contexte cible, celui qui est associé
à la structure objet cible. Un sous-ensemble de ce dernier est modifiable (affectable).
Dans le métalangage, on précise sous forme d'un "code origine", l'élément du contexte complétant la variable figurant en
opérande d'une expression. Pour une expression faisant intervenir un élément unique du contexte, cette origine peut
précéder l'expression (par exemple pour les conditions propres). Une convention mixte, se retrouve en expression
d'affectation, avec le code origine de l'élément affecté précédant l'expression, qui elle-même comporte des opérandes, soit
sans code origine associé, soit avec code origine explicité (origines par défaut).
Exemples d'expressions:
A:
V3 -E- 1 -ET- V2 -E- 1.
UL := UL(X), VPC := VPC(@Y), V3 := V3(çZ).
Expressions de conditions.
Elles sont construites à partir des opérateurs booléens "et" (-ET-), "ou" (-OU-) et "non" (-N-), s'appliquant à des relations
(égalité (-E-), inclusion (-INC-), etc ... ) dont les arguments sont mis en relation avec des valeurs d'étiquettes (<TSUNI>
(IV.16) ). Ces valeurs d'étiquettes sont elles-mêmes calculées à partir d'expressions où figurent des opérateurs tels que union
(-U-), intersection (-I-), somme (+), etc ..., et d'opérandes qui sont directement des valeurs d'étiquettes du contexte.
Les opérandes internes à une unité syntaxique "<TSUNI>", sont donc reliés par des opérateurs -U-, -I-, etc ... et constituent
une suite qui fait intervenir les deux propriétés, celle de dépendances entre variables (induite par leur forme arborescente),
et celle de compatibilité. Le premier opérande (qui est toujours un nom de variable) joue un rÔle particulier, puisqu'il
constitue la racine du sous-arbre des déclarations de variables où se fera la recherche des opérandes suivants acceptés en
tant que dépendants. Ces opérandes seront associés à des sous-variables du premier opérande qui peuvent être des variables
élémentaires. Ils pourront être également des valeurs de variables, auquel cas ils suivront immédiatement la variable
élémentaire associée. La compatibilité se traduit, elle, par l'emploi possible comme opérande, de toute variable appartenant
à la même classe que la variable qui précède. Cela reste vrai pour le premier opérande.
Le deuxième membre d'une relation se construit de la même façon. Le premier opérande de ce deuxième membre obéit aux
mêmes règles que les opérandes non initiaux du premier membre.
Des exemples ont été présentés au chapitre déclarations des variables.
On distingue des expressions de "conditions propres" s'appliquant à une valeur de décoration unique, et des expressions de
"conditions intersommets" s'appliquant à plusieurs valeurs de décorations.
12
Expressions d'affectations.
Elles comportent un membre gauche, constitué d'une variable (élémentaire ou générale) associée à un élément affectable du
contexte. Le membre droit est constitué d'une expression analogue au membre droit d'une relation.
Réseaux d'affectations conditionnelles.
C'est une structure construite sur les expressions de conditions et d'affectations, permettant de "moduler" les affectations,
selon les valeurs des conditions de façon analogue aux "cond" de LISP. Elle se construit comme un réseau avec des
opérations de choix (alternants) entre différentes séquences d'opérations. La syntaxe (hors-contexte) est présentée en (IV.1)
et (IV.2). Ces structures sont trivialement isomorphes à des arbres ET/OU. Dynamiquement, un réseau peut être interprété:
- soit de façon déterministe, la séquence des affectations réalisées étant constituée par le premier chemin allant
de l'entrée à la sortie du réseau, dont les conditions sont vérifiées à chaque étape de la séquence. Une
contrainte du type "le dernier arc sortant d'un point de choix doit être inconditionnel" assure qu'un tel chemin
existe toujours.
- soit de façon non déterministe, la contrainte d'arc inconditionnel étant alors levée. La séquence des
affectations réalisées est également le premier chemin dont les conditions sont vérifiées a chaque étape, ou la
séquence vide.
LES PROCEDURES.
L'introduction des procédures dans les métalangages des différents LSPL, permet d'obtenir une organisation des données
linguistiques plus compacte et plus claire. Ces procédures sont toutes liées au traitement des décorations et se répartissent
en:
- procédures de conditions, équivalentes à une expression de condition, donc fonctions à valeur booléenne,
- procédures d'affectations, équivalentes à une liste d'expressions d'affectations,
- procédures d'affectations conditionnelles, équivalentes à un réseau d'affectations conditionnelles (calcul de
valeurs de décorations).
Les procédures se présentent comme des expressions de même type que les expressions auxquelles elles sont équivalentes,
mais elles sont paramétrées par rapport aux éléments du contexte intervenant dans le LSPL auxquels elles sont associées.
Les origines possibles constituent la liste des paramètres formels de la procédure. L'appel de procédure ($<ndp>...), est
réalisable à l'intérieur d'une expression du même type, et il peut constituer, à lui seul, la totalité de l'expression. La
procédure appelée voit ses paramètres formels substitués par les valeurs des paramètres de l'appel, en respectant les
correspondances de positions d'arguments.
L'appel de procédure d'affectation peut faire exception à cette convention. Selon le contexte de l'appel, on devra, dans
certains cas, augmenter la liste des valeurs d'appel par un code origine associé à l'élément affecté (c'est le premier élément
de la liste, il est suivi de ";"), alors que dans la définition de procédure correspondante, cet élément reste implicite
(<APROCAF> (IV.8) ). C'est le cas, notamment, dans les réseaux d'affectations conditionnelles.
Une définition de procédure d'étiquette ne peut comporter d'appels de procédures, par contre, une définition de procédure
réseau peut comporter des appels de procédures d'étiquettes (conditions intersommets et affectations), aussi bien que des
appels de procédures réseaux. Les valeurs d'appel des procédures sont alors des paramètres formels de la procédure ainsi
définie.
On évite une structure circulaire des définitions, en imposant des références arrières aux procédures réseaux ainsi appelées
(elles doivent être précédemment définies).
13
BASE COMMUNE AUX LSPL TRACOMPL ET EXPANS (MONOLINGUE ET
BILINGUE).
Avant de présenter ces LSPL de façon détaillée aux paragraphes VII et VIII, nous développons ici la partie du métalangage
qui constitue une base commune pour les LSPL TRACOMPL et EXPANS (dans ses différents modes). Les modèles sousjacent à ces différents LSPL ont tous en commun la propriété d'être biétiquetés, propriété qui conditionne étroitement les
aspects du métalangage liés aux décorations. De plus le LSPL EXPANS inclue lui-même un LSPL TRACOMPL. Cette base
commune recouvre donc les trois composantes:
- déclaration des variables,
- définition des procédures,
- réseaux d'affectations conditionnelles, que nous présentons ci-après.
Déclarations de variables.
Pour les deux modes du LSPL EXPANS et pour le LSPL TRACOMPL, les conventions générales exposées au chapitre II
s'appliquent. Les trois types de variables: exclusives, non exclusives et arithmétiques sont utilisables. La définition des
variables générales a la forme présentée en (II.1). Tous ces modèles sont biétiquetés, donc les conventions d'utilisation des
préfixes "$" et "$$" s'appliquent. Il en résulte la déclaration de deux jeux de variables source et cible pour une même phase.
Pour toutes ces phases, les déclarations de variables intègrent également des définitions de procédures et un réseau
d'affectations conditionnelles complémentaire, qui sont présentés dans la suite de ce paragraphe. Même si, pour des raisons
de commodité, le tout est intégré en un fichier unique, ces deux dernières parties ne peuvent plus être considérées comme
des déclarations de variables, mais comme l'équivalent d'une règle de réécriture.
14
On retrouve les relations associées aux variables, relations de dépendance et de compatibilité, internes à un jeu, ou étendues
entre jeux différents. Pour la syntaxe de la partie propre aux déclarations de variables, on se reportera aux diagrammes (I.1)
à (I.4).
Procédures.
Les procédures, telles qu'elles figurent dans les LSPL EXPANS et TRACOMPL, présentent des aspects très particuliers par
rapport à leurs équivalents des LSPL ATEF et ROBRA. Cela est d– à la nature biétiquetée des nouveaux LSPL d'ARIANEG5. Signalons que bien que le LSPL TRANSF d'ARIANE-78 fut lui aussi biétiqueté, le problème de contexte était réduit,
dans la mesure où il comportait des procédures de conditions associées uniquement au contexte source et des procédures
d'affectations portant uniquement sur le contexte cible.
En plus de l'extension, par rapport au LSPL TRANSF, du contexte source du LSPL EXPANS en mode monolingue ou
bilingue, l'introduction de réseaux d'affectations conditionnelles à fonctionnement non déterministe, où les conditions
portent sur le contexte global, se traduit en pratique, par l'utilisation de procédures pouvant s'interpréter indépendamment
des jeux de décorations (1 ou 2) impliqués. Dès lors, se posait un problème d'interprétation des opérandes de l'expression
associée à une définition de procédure, vis-à-vis des différents jeux possibles. On aurait pu choisir une solution où tout
paramètre aurait été associé à un jeu unique (typage des paramètres par rapport aux jeux de décorations).
Cela nous aurait mené aux conventions suivantes (X est un paramètre de définition de procédure):
a) @X -> paramètre lié à un élément appartenant au jeu 1,
b) çX -> paramètre lié à un élément appartenant au jeu 2 (valeur initiale),
c) X -> paramètre lié à un élément appartenant au jeu 2 (valeur courante).
Ces conventions sont celles qui sont adoptées hors des définitions de procédures.
Ce choix risquait de se traduire par une multiplication des définitions d'une même procédure, si elle devait s'appliquer, pour
un certain nombre d'opérandes, aux jeux 1 et 2. En fait, on a choisi de pouvoir faire figurer en paramètre le type "jeu 1" ou
"jeu 2", tout en conservant le bénéfice de paramètres pour lesquels ce type est déterminé. On a donc gardé les conventions
a) et b) pour les types de paramètres prédéterminés, par contre pour c), le paramètre X est considéré comme associable a
priori aussi bien au jeu 1 que 2.
On notera donc que l'interprétation de "@" et "ç" diffère selon que l'on se place dans une définition de procédure, ou en
dehors. En résumé, les conventions retenues pour les procédures sont:
a') @X -> paramètre lié à un élément appartenant au jeu 1,
b') çX -> paramètre lié à un élément appartenant au jeu 2 (mais pas obligatoirement une valeur initiale),
c') X -> paramètre non lié à un jeu particulier.
Une liste de paramètres se présentera ainsi:
PROC110A (@X, çY, Z, çT) ==
...
jeu 1 -> X, Z.
jeu 2 -> Y, Z, T.
Un certain nombre de contraintes liées à l'utilisation de ces types ont pour origine des propriétés de compatibilité.
15
Une première contrainte traduit l'impossibilité d'extension des valeurs de type d'un paramètre (en tant que propriété héritée).
Il en résulte que l'emploi de valeurs "X", à l'intérieur de l'expression définissant la procédure (en codes origines), lorsque le
paramètre formel est "@X" ou "çX", est interdite.
Pour la même raison, l'emploi de "@X", pour un paramètre "çX", ou réciproquement de "çX", pour "@X", est également
illicite. La restriction de valeurs de type est licite. Il en résulte la table de compatibilité d'usage suivante:
paramètre formel.
emploi possible.
@X
çY
Z
@X
çY
@Z, çZ ou Z
->
->
->
Une seconde source de contraintes de types provient de la nature des variables associées aux différents paramètres.
a) - une variable déclarée $$V1, (sans V1), induit l'appartenance au jeu 1 seul, de (ou des) l'opérande associé:
V1(çX) est donc un opérande illicite,
b) - une variable déclarée V2, (sans $$V2), induit l'appartenance au jeu 2 seul, de (ou des) l'opérande associé:
V2(@X) est donc un opérande illicite,
c) - une variable déclarée $V3 est considérée comme une unique variable, trouvant son interprétation aussi
bien par rapport au jeu 1, qu'au jeu 2.
V3(@X) forcera une interprétation de l'opérande par rapport au jeu 1,
V3(çX) forcera une interprétation de l'opérande par rapport au jeu 2,
V3(X) garde ses deux interprétations possibles, indifféremment par rapport aux jeux 1 et 2.
d) - Si des variables de même nom, déclarées $$V4 et V4, ne sont pas de types et de cardinalités identiques,
elles ne peuvent être mises en relation (sauf si elles sont de type arithmétique). Par contre, en cas d'identité de
ceux-ci, elles peuvent être mises en relation à l'intérieur d'une expression, et de plus il est possible de les
utiliser en tant qu'opérandes liés indifféremment aux jeux 1 ou 2 dans les procédures. Remarquons que lors de
l'appel effectif d'une procédure, un paramètre se voit associer une valeur unique représentative du jeu 1 ou du
jeu 2, valeur qui doit s'appliquer à tous les opérandes de l'expression où ce paramètre figure. On notera que
dans une définition de procédure, le type des variables permet de synthétiser un type correspondant aux
paramètres. Si le type synthétisé est vide, c'est que l'emploi de ce paramètre est incorrect.
Exemple:
--> Déclarations des variables:
$$V1
== (A,B,C).
V2
V1 appartient au jeu 1, V2 appartient au jeu 2.
--> L'expression:
16
== (1,2,3).
V1(X) -I- V2(X)
est illicite, car la valeur effective associée à X appartient au jeu 1 ou au jeu 2, mais non aux deux à la fois.
On notera que cela fait intervenir la relation de compatibilité de variables entre deux jeux distincts:
$$V1
== (1,2).
V1
== (3,2,1).
$$V2
== (1,2,3).
V2
== (2,1).
jeu 1
jeu 2
--> Expression:
V1(X) -I- V2(Y) -INC- 1
Les opérandes de cette expression ne peuvent trouver d'interprétation complète si X et Y sont associés à un même jeu,
même si on peut leur en trouver une individuellement.
--> Expression:
V1(X) -I- V2(X) -INC- 1
Cette expression n'est jamais interprétable, quelle que soit la valeur de X, car les relations entre opérandes induites par la
compatibilité sont incompatibles avec celles qu'induit le paramètre X.
C'est au stade de la compilation des procédures que sont détectées les expressions incorrectes, c'est-à-dire dont les
opérandes ne pourraient pas tous trouver une interprétation unique par rapport aux jeu 1 et 2. Si l'on se reporte aux alinéas a)
à d) présentant les différents cas de déclarations de variables:
- les cas a) et b) ne posent jamais de problème, le compilateur se sert du type de la variable pour contraindre le type des
paramètres associés,
- le cas c) ne pose pas de problème particulier, l'interprétation des opérandes est réalisée par rapport aux deux
jeux, par le compilateur. L'indétermination est levée dynamiquement lors de l'évaluation de l'expression. Cette
approche est possible, car l'on considère en fait, une seule et même variable qui intervient dans les deux jeux
de décoration.
- le cas d), comme on vient de le voir, pose des problèmes plus délicats. L'introduction d'un type précis avec le
paramètre d'une variable, permet la sélection d'un jeu unique pour cette variable qui est, dès lors, utilisable
comme toute autre variable définie selon les cas a) ou b). C'est ainsi que "V4(@X)" ou "V4(çX)" sont des
opérandes licites dans un expression de condition intersommets.
17
Si l'on opte pour l'emploi d'un paramètre lié aux deux jeux: "X", les conventions mises en œuvre se présentent comme un
élargissement des conventions précédemment adoptées, où il était indispensable d'utiliser un type précis. Si les variables
relatives à chacun des deux jeux sont compatibles (même type et même cardinalité), l'opérande sera considéré comme
associable aux deux jeux simultanément. Lorsque des valeurs associées à la variable apparaissent dans la sous-expression, à
ces valeurs peuvent correspondre des propriétés différentes. Les variables de même nom dans les deux jeux étant de même
cardinalité, le nombre des valeurs associées à chaque variable est le même. Des correspondances sont établies entre les deux
jeux. Si deux valeurs de même nom apparaissent, ce sont ces valeurs, prises dans chacun des jeux, qui interviennent. Elles
peuvent correspondre à une même position dans les déclarations ou non. Si le nom de valeur est propre à un jeu, il y a mise
en correspondance automatique avec la valeur de même position dans les déclarations de l'autre jeu. Selon le type du
paramètre d'appel, la valeur effectivement prise en compte sera l'une ou l'autre. Remarquons que la correspondance d'ordre
des noms de valeurs entre les deux jeux pour cette variable peut ne pas être respectée.
Exemple
$$V4
V4
== (1,B,4,C).
== (1,2,3,4).
--> jeu 1.
--> jeu 2.
Les valeurs "1" et "4" sont communes aux deux jeux. La correspondance de position est vérifiée pour "1" mais pas pour "4".
Les valeurs "B" et "C" sont propres au jeu 1, "2" et "3" au jeu 2.
--> L'expression:
V4(X) -E- 1 -U- 4.
est licite. La valeur "4" sera la troisième valeur déclarée dans le jeu 1 et la quatrième dans le jeu 2.
--> L'expression:
V4(@X) -E- 1 -U- 4.
s'appliquera au jeu n˝ 1. La valeur "4" sera donc la troisième déclarée.
--> L'expression:
V4(çX) -E- 1 -U- 4.
s'appliquera uniquement au jeu n˝ 2. La valeur "4" sera la quatrième déclarée.
Les valeurs prises en compte dans une sous-expression sont celles qui sont associées à la variable dans le jeu effectivement
déterminé par le type du paramètre d'appel. De plus, les relations de compatibilité peuvent intervenir entre les valeurs des
deux jeux selon les règles habituelles.
18
Exemple
$$GNR
GNR
== (A,B,C).
== (1,2,B).
--> jeu 1.
--> jeu 2.
Seule la valeur "B" est commune aux deux jeux. Il n'y a d'ailleurs pas correspondance de position pour elle. Les
correspondances implicites de "A" vers "1" (et réciproquement), de "2" vers "B" (jeu 1) et de "C" vers "B" (jeu 2) sont
effectuées.
--> Valeurs de GNR selon les paramètres:
@X
@Z
çZ
-->
-->
-->
GNR(A,B)
GNR(A,B)
GNR(1,2)
--> jeu 1.
--> jeu 1.
--> jeu 2.
--> Expression:
GNR(Z) -I- (A -U- B) -I- GNR(@X)
--> Résultat:
si Z appartient au jeu 1 (@Z), on obtient GNR(A,B) (sur jeu
1),
si Z appartient au jeu 2 (çZ), on obtient GNR(1) (sur jeu 2).
Pour les procédures de conditions propres ou d'affectations qui comportent des origines implicites, il y a également
obligation de préciser le type de ce paramètre implicite. Cela est indispensable, dans la mesure où le contexte seul ne permet
pas d'associer un type déterminé à ce paramètre implicite. Dans le LSPL EXPANS, un appel de procédure de condition
propre est substituable à un appel de procédure de condition intersommets à l'intérieur des réseaux d'affectations
conditionnelles de ce LSPL. Le contexte peut donc s'appliquer aussi bien au jeu 1 qu'au jeu 2. On a donc adopté les
formalismes (voir (II.2) ) :
a)
PCP(@) :
<DPCP>
opérandes liés au jeu 1,
19
b)
PCP(ç) :
<DPCP>
utilisables lorsque cela s'impose, sinon le formalisme habituel:
c)
PCP
:
<DPCP>
reste accepté.
Note: lors de la conversion d'une application TRANSF (ARIANE-G5) en une application EXPANS-2 (ARIANE-G5), on
utilisera systématiquement la forme a).
De même pour les procédures d'affectations:
- le sommet affecté est toujours lié au jeu 2,
- les sources d'affectations peuvent appartenir aux jeux 1 ou 2.
Pour les opérandes sans origine explicitement associée et pour lesquels il y aurait ambiguïté d'appartenance, on tient compte
de conventions analogues aux précédentes (voir (II.2) )
a)
PAF(@) :
<DPAF>
b)
PAF(ç) :
<DPAF>
<DPAF>
reste accepté.
sinon le formalisme standard:
c)
PAF
:
Note: lors de la conversion d'une application TRANSF en EXPANS-2, on utilisera systématiquement la forme b).
Notons également que, si l'utilisation des variables induit des contraintes de types sur les paramètres de définition de
procédures, l'appel de procédure interne à une définition de procédure (cas des procédures réseaux) induit également de
telles contraintes qui doivent être propagées (au stade de la compilation) jusqu'aux niveau des appels primaires (hors
définition de procédures), de façon à prendre en compte la cohérence globale d'utilisation des procédures.
Exemple:
PCP1 (@) :
PCP2 (ç) :
V4 -E- 2.
V4 -E- 4.
PRCA1 (X,...)
==
...
PCP1 porte sur le jeu 1.
PCP2 porte sur le jeu 2.
$PCP1(X) -ET- $PCP2(X) ...
est illégale dans la mesure où le paramètre X ne pourra être associé à aucun jeu.
Les autres aspects concernant les procédures ne sont pas particuliers à ARIANE-G5, et on pourra se reporter au DSE1 ((1)
DSE-1 D-III-3-1).
La syntaxe correspondant aux définitions de procédures est présentée par les diagrammes (II.1) à (II.9). On notera que, pour
passer des définitions de procédures en TRANSF (où les procédures réseaux n'étaient pas utilisables), aux définitions de
procédures en EXPANS-2 (mode bilingue), on doit passer d'un schéma:
20
-PCP-
<lpcp>
-PAF-
<lpaf>
-FIN-
avec <lpcp> = <liste_des_procédures_de_conditions_propres>,
<lpaf> = <liste_des_procédures_d'affectations>.
à un schéma:
-PROC- <lcet>
-PRCA-
<lprca>
-FIN-
avec <lcet> = <liste_des_proc._cp_ou_paf_ou_pcis
précédées_de_PCP_ou_PAF_ou_PCIS>,
<lpaf> = <liste_des_proc._réseaux>.
Réseaux d'affectations conditionnelles.
Les réseaux d'affectations conditionnelles introduits dans les LSPL TRACOMPL et EXPANS, s'inspirent de ceux qui
figurent dans le LSPL ROBRA d'ARIANE-78. Comme eux, leur rôle est d'introduire une modulation des affectations dans
une règle. Toutefois une extension sémantique importante a été apportée, puisque l'on passe d'un réseau à interprétation
déterministe, avec contexte lié aux conditions et restreint au contexte source, à un réseau à interprétation non déterministe,
avec contexte lié aux conditions englobant les deux contextes source et cible.
Du point de vue syntaxique, le changement est mineur, puisqu'il se traduit simplement par la levée de la contrainte "dernier
arc sortant d'un nœud inconditionnel" (ce que traduisent les diagrammes (IV.1) et (IV.2)).
Le fonctionnement, non déterministe unaire, correspond à l'interprétation suivante:
- s'arrêter au premier chemin allant de l'extrémité initiale à l'extrémité terminale du réseau, tel que, à chaque
étape, les conditions d'étiquettes faisant intervenir le contexte source "(@X)", le contexte initial "(çX)" et les
valeurs courantes du contexte cible "(X)", soient vérifiées. S'il s'avère qu'un tel chemin n'existe pas, considérer
que le réseau ne fait aucune transformation sur la valeur de l'état courant. L'automate réalisant ce calcul met en
œuvre une technique de "backtracking" tout à fait classique.
On peut considérer que, dans les LSPL TRACOMPL et EXPANS, toutes les affectations sont réalisées par un réseau
implicite, dont le niveau principal est réduit à un arc unique, et dont l'écriture est régie par une syntaxe particulière aux
LSPL où il s'intègre.
21
On trouvera dans les diagrammes (IV.1) à (IV.5), les règles de syntaxe d'écriture des réseaux. Comme en ROBRA, on a
gardé l'emploi possible des deux types de marquants (<RESAS1> et <RESAS2> (IV.1)). Le choix fait doit être constant
pour chaque réseau, et il est déterminé par celui qui a été fait au niveau principal.
LE LSPL TRACOMPL.
Principes généraux.
L'intérêt d'un modèle arbre->arbre ne faisant intervenir aucune propriété géométrique de la structure d'arbre, mais
permettant d'effectuer une transposition générale des valeurs d'étiquettes prises sur un jeu 1, vers un jeu 2, est évident. Il
permet de ramener des arbres de provenances diverses, et donc à jeux de décorations différents, vers une structure de
décoration unique. Pour définir un tel modèle, les choix faits se sont inspirés de la forme générale des affectations
conditionnelles de ROBRA. Le contexte auquel s'applique ce réseau est restreint à trois éléments:
- un nœud appartenant au contexte source "(@S)", lié au jeu 1;
- un nœud appartenant au contexte cible, correspondant à une valeur initiale d'étiquette (non modifiable), sur le
contexte cible "(çS)", et obtenue, à partir de "@S", par application de REFORM;
- un nœud appartenant au contexte cible, dont la valeur d'étiquette est modifiable, et qui constitue le nœud
courant, "(S)", du réseau d'affectations conditionnelles. La valeur initiale de "S" est "çS", la valeur finale, qui
sera associée à la structure cible, sera celle qui se déduit de l'application du réseau, conformément à ce qui est
présenté au paragraphe VI.3.
Par contre, on a étendu la puissance du calcul des valeurs d'étiquettes par l'introduction d'un fonctionnement du réseau, non
déterministe et unaire (à un seul résultat), ainsi que par la prise en compte de deux jeux de décorations simultanés (2).
On peut considérer que le réseau "-CVAR-", qui a été intégré au fichier des déclarations de variables (modèle biétiqueté),
représente en fait, une règle grammaticale sans composante géométrique. On a également autorisé l'utilisation des
procédures (étiquettes et réseaux) dans ce même fichier. Par contre, l'utilisation de formats ("*<ndf>" ou "+<ndf>") a été
rejetée (pour des raisons de simplicité de l'organisation des compilations).
Composante algorithmique.
La structure arborescente cible étant identique à la structure arborescente source, le LSPL fonctionnant comme un modèle
de création, l'automate procède par parcours préfixé de l'arborescence source, création, en parallèle, des nœuds de
l'arborescence cible et association à ces nœuds d'une valeur d'étiquette, d'abord initialisée par "REFORM", puis évaluée par
application du réseau.
Le contexte correspond au schéma qui a été présenté au paragraphe III.3.
Détail des données linguistiques.
Une seule composante, constituée par le fichier dit des "déclarations de variables", qui regroupe les déclarations de variables
proprement dites, les définitions de procédures éventuelles, et un réseau qui peut être vide (Le LSPL TRACOMPL se réduit
alors au LSPL REFORM). La syntaxe générale correspond au diagramme (I.1).
Exemple:
-EXC$V1
== (A1,A2,A3,A4,A5,A6,A7,A8).
22
$V11
== (B1,B2,B3,B4).
$VPA
$VPCX
$VPDX
$$VPAX1
$$VPBX1
==
==
==
==
==
(C1,C2,C3,C4).
(D1,D2).
(E1,E2).
(1,2,3,4).
(1,2,3,4).
$$VPB1
VPGX
== (1,2,3,4).
== (F1,F2,F3).
-NEX-
$$VAL
$V2
$VPC
$V3
$VPF
$VPFX
$$VPE1
VPHX
== (A,B,C,D,E,F,G,H,I).
==
==
==
==
(G1,G2,G3,G4,G5,G6,G7,G8).
(H1,H2,H3,H4).
(I1,I2,I3,I4).
(J1,J2).
== (1,2,3,4).
== (1,2,3,4).
== (K1,K2,K3,K4).
-ARITH-
$$VPD
$$V4
$$V5
== (15).
== (255).
== (16).
23
$$VPH
$$VPG1
== (8).
== (12).
-PROCPCP:
PCP:
PCP:
PCIS2
PCIS1
PCP1
== V3 -NE- V30 -ET- V2 -NE- V20 .
== V3 -E- I1 -ET- V2 -E- G1 .
== V2 -E- G1 .
PCIS:
PAF:
PAF:
PCIS:
PCIS2(X,Y)
PAF2
PAF1
PCIS1(X,Y)
==
==
==
==
VPC(X) -U- VPC(Y) -E- H1 .
VPFX := 1 -U- 4 .
VPC := H2 .
V3(X) -E- I1 -ET- V2(Y) -E- G1 .
-PRCAPRCA1(X;Y,Z)
== (:
V3(Y) -NE- I1 :: VPFX(X) := 2 -U- 3
|
::
VPFX(X) := VPFX(Y) -U- 1 -U- 2 -U- 3 :).
PRCA2(X;çY,@Z)
== (: $PCIS1(@Z) -ET- $PCIS2(çY)
::
VPF(X) := J1, $PAF1(X)
| V3(@Z) -E- I2 -ET- V2(@Z) -E- G1
::
VPF(X) := J2
| V3(@Z) -E- I3 -ET- V2(@Z) -E- G1
::
VPF(X) := J1 -U- J2 :) .
24
-CVARS:çS ; (: :: VPFX(S) := VPFX(S) -U- 1
(: V2(@S) -E- G1 -OU- V2(@S) -E- G2
::
VPFX(S) := VPFX(S) -U- 2 , $$PRCA2(S;çS,@S)
** $$PRCA2 est l'appel à la procédure réseau PRCA2 .
| V2(@S) -E- G2 :: VPFX(S) := VPFX(S) -U- 3
(:
V3(@S) -E- I1
::
VPF(S) := J1
|
V3(@S) -E- I2
::
VPF(S) := J2
|
:)
V3(@S) -E- I3
::
VPF(S) := J1 -U- J2
:)
| V2(S) -NE- V20 -ET- $PCIS2(S,@S)
-OU- UL(@S) -E- 'ULAS1'
::
$PAF2(S) , VPFX(S) := VPFX(S) -U- 4 , UL(S) := 'ULCOPL1'
| ::
:)
-FIN-
LE LSPL EXPANS EN MODE MONOLINGUE ET BILINGUE.
Principes généraux.
Ce sont deux modes d'un même LSPL qui reprennent la philosophie du LSPL TRANSF (ARIANE-78). C'est-à-dire qu'ils se
veulent des LSPL réalisant des transformations réduites arbre->arbre, sur la base de l'utilisation d'informations de nature
essentiellement lexicale, mais constituée en articles à valeurs non statiques, qui sont en fait des règles. Le but est en quelque
sorte, de pouvoir procéder, en tout endroit d'une chaîne de traduction, à un "enrichissement lexical" des structures. Le LSPL
EXPANS s'intègre dans le système ARIANE-G5, où l'enchaînement des différents type de phases est ouvert. Le but de cette
organisation est d'offrir une possibilité de redistribution des informations de nature lexicale plus rationnelle qu'en ARIANE78, (où seules les phases "AM" (ATEF), "TL" (TRANSF) et "GM" (SYGMOR) intègrent des lexiques (1)).
On présente simultanément les formes monolingue et bilingue du LSPL EXPANS, car ces formes sont quasi identiques.
Elles diffèrent uniquement par une propriété relative aux valeurs d'Unités Lexicales. Pour un LSPL EXPANS en mode
monolingue (EXPANS-1), les valeurs d'UL des décorations source et cible sont considérées comme appartenant à un jeu
unique, pour un LSPL EXPANS en mode bilingue (EXPANS-2), ces valeurs sont considérées comme appartenant à deux
jeux distincts. Il en résulte qu'une phase écrite en EXPANS-1, verra son lexique utilisé pour couvrir les cas d'exception,
alors qu'une phase écrite en EXPANS-2, aura normalement un lexique qui couvrira l'essentiel des entrées lexicales de
l'application.
Pour ces deux formes du LSPL EXPANS on a défini une organisation compatible avec celle du LSPL TRANSF, mais en la
généralisant (2). Parmi les points similaires et les différences citons:
25
- une organisation des données linguistiques en déclarations de variables, fichier des définitions de procédures,
un ensemble constitué de 1 à 8 dictionnaires,
- des déclarations de variables explicitant la propriété de biétiquetage, et intégrant un réseau d'affectations
conditionnelles (donc une phase TRACOMPL complète),
- la prise en compte des réseaux d'affectations conditionnelles à fonctionnement non déterministe unaire, en
particulier dans les définitions de procédures (limitées aux procédures d'étiquettes dans TRANSF), ainsi que
dans les dictionnaires,
- l'introduction d'un dictionnaire dit: "dictionnaire zéro", permettant un traitement plus souple de cas
d'exception (calcul de valeurs de chaînes d'UL cibles possible),
- une gestion des dictionnaires selon deux modes au choix:
a) prise en compte uniquement du premier article (selon un ordre défini sur les dictionnaires)
correspondant à la valeur d'UL de l'élément courant du contexte source (mode donnant la
compatibilité TRANSF),
b) prise en compte de l'ensemble des articles des différents dictionnaires qui correspondent à cette
même valeur d'UL source (4),
- l'extension du contexte source associé aux articles des dictionnaires à une configuration figée recouvrant
quatre sommets de la structure source (TRANSF a un contexte source réduit à l'unique sommet courant).
Composante algorithmique.
Elle est dérivée de celle de TRANSF. Le LSPL fonctionne également comme un modèle de création.
Au stade du chargement des données linguistiques (qui précède une exécution), on fait intervenir dans un ordre précis, les
dictionnaires généraux (de 1 à 7), pouvant être référencés lors d'une exécution. Dans tous les cas, la consultation des
dictionnaires sera effectuée en respectant cet ordre. Le mode monodictionnaire, donnant la compatibilité TRANSF, se
traduira par la prise en compte de l'article du premier dictionnaire où se trouve la valeur d'UL source cherchée. En mode
multidictionnaire, on consulte tous les dictionnaires, ne retenant que ceux qui figurent dans une liste d'activation précisée en
paramètre de l'exécution (3). Cette liste permet de sélectionner, pour une exécution donnée, le sous-ensemble de
dictionnaires à activer, par rapport à l'ensemble des dictionnaires chargés. Le numéro du triplet d'action par défaut, à
prendre en considération le cas échéant, est également passé en paramètre de l'exécution.
Le schéma général de fonctionnement de l'automate est présenté ci-après.
A chaque étape, l'automate part de la valeur d'UL source, pour procéder aux consultations (utilisation d'un hash-code et
d'index denses) des dictionnaires, en respectant l'ordre défini par les chargements. En mode monodictionnaire, il s'arrête sur
le premier dictionnaire trouvé, où figure un article correspondant à la valeur d'UL source. En mode multidictionnaire, il tient
compte de la liste d'activation (l'ensemble des dictionnaires activés est stable pour une même application, et le métalangage
ne comprend donc pas de contrôle explicite de cet ensemble).
Puis l'automate effectue, pour chacun des dictionnaires, une sélection de l'entrée de l'article (triplet) acceptable, au vu des
conditions associées à chaque triplet et portant sur le contexte source (conditions de sélection). Le dernier triplet d'un article
ne pouvant comporter de condition, il existe toujours un tel triplet par article de dictionnaire sélecté. Pour chaque triplet
sélecté, l'automate effectue la transformation indiquée, par prise en compte des parties arborescence et affectations. Il y a
initialisation des valeurs d'étiquettes de l'arborescence image (qui peut se réduire à un sommet unique), par application du
LSPL TRACOMPL intégré, sur le sommet courant origine "(@S)". Comme en TRANSF, les éventuels dépendants de la
racine du transformé sont insérés à gauche de l'image des dépendants du sommet source courant.
En mode multidictionnaire, et lorsqu'il y a prise en compte d'articles multiples pour un même sommet courant, c'est, en fait,
la forêt constituée par les arborescences transformées qui prend cette place, l'image du nœud courant étant alors un nœud
26
qui couvre ces racines, dit "nœud racine multidictionnaire". Pour ce nœud, on utilise l'article du dictionnaire zéro,
correspondant au calcul de la valeur d'étiquette de cette racine, à partir des valeurs d'étiquettes associées aux racines des
transformés provenant des différents dictionnaires. En mode multidictionnaire, lorsqu'un seul article convient, le résultat est
celui que l'on obtiendrait en mode monodictionnaire.
Toujours dans ce même mode multidictionnaire, lorsque la prise en compte de la liste d'activation a pour conséquence
qu'aucun article candidat des dictionnaires généraux ne peut s'appliquer, on lance la recherche de l'article du dictionnaire
zéro sélectionné pour l'action par défaut. De un à huit articles de cette sorte peuvent figurer. Ces articles sont
inconditionnels, ne contiennent pas d'arborescence, mais peuvent comporter l'appel à une expression d'affectation de valeur
chaîne d'UL (on crée une valeur d'UL dynamique), suivi d'un éventuel réseau d'affectations conditionnelles.
Si le dictionnaire zéro n'existe pas, l'action par défaut sera constituée par le transfert de la valeur chaîne d'UL source. Enfin,
si la valeur d'UL source est une valeur non statique (ce qui signifie qu'elle ne figure nulle part dans les données linguistiques
associées au LSPL), c'est la valeur de chaîne de l'UL source qui est passée, les variables étant calculées par application de la
composante TRACOMPL (déclarations de variables) de la phase.
Détail des données linguistiques.
Elles se composent:
27
- des déclarations de variables,
- des fichiers de formats sources et cibles,
- du fichier des définitions de procédures,
- des dictionnaires généraux de 1 à 7,
- d'un dictionnaire particulier numéro zéro.
Déclarations de variables.
Elles sont strictement identiques à celles du LSPL TRACOML. Elles déterminent les jeux de décorations 1 et 2, ainsi que la
phase TRACOMPL, appliquée à partir de la valeur d'étiquette du nœud courant source, pour obtenir la valeur d'étiquette
(sur jeu 2) qui servira à initialiser les nœuds du transformé.
Exemple:
-EXC$$VPAX1
$$VPB1
VPEX
== (1,2,3,4).
== (1,2,3,4).
== (1,2,3).
-NEX$VAL
$V2
VPE
$$VPE1
$VPC
$V3
$VPF
VPFX
==
==
==
==
==
==
==
==
(A,B,C,D,E,F,G,H,I).
(1,2,3,4,5,6,7,8).
(1,2,3,4).
(1,2,3,4).
(1,2,3,4).
(1,2,3,4).
(1,2).
(1,2,3,4).
-ARITH$VPD
$V5
$VPH
== (15).
== (16).
== (8).
28
VPHX
== (5).
-PROCPCP:
PCP:
PCP:
PCIS:
PAF:
PAF:
PCIS2
PCIS1
PCP1
PCIS2(X,Y)
PAF2
PAF1
==
==
==
==
==
==
V3 -NE- V30 -ET- V2 -NE- V20 .
V3 -E- 1 -ET- V2 -E- 1 .
V2 -E- 1 .
VPC(X) -U- VPC(Y) -E- 1 .
VPFX := VPFX -U- 4 .
VPC := 2 , VPD := 1 , V5 := 8 ,
VPHX := 4 .
PCIS: PCIS1(X,Y) == V3(X) -E- 1 -ET- V2(Y) -E- 1 .
-PRCAPRCA1(X;Y,Z)
== (: V3(Y) -NE- 1 :: VPFX(X) := 2 -U- 3
| ::
VPFX(X) := VPFX(Y) -U- 1 -U- 2 -U- 3 :).
PRCA2(X;çY,@Z) == (: $PCIS1(@Z) -ET- $PCIS2(çY)
::
VPF(X) := 1, $PAF1(X)
| V3(@Z) -E- 2 -ET- V2(@Z) -E- 1
::
VPF(X) := 2
| V3(@Z) -E- 3 -ET- V2(@Z) -E- 1
::
VPF(X) := 1 -U- 2 :).
-CVARS:çS ; (: :: VPFX(S) := VPFX(S) -U- 1
(: V2(@S) -E- 1 -OU- V2(@S) -E- 2
:: VPFX(S) := VPFX(S) -U- 2 , $$PRCA2(S;çS,@S)
| V2(@S) -E- 2 :: VPFX(S) := VPFX(S) -U- 3
(: V3(@S) -E- 1 ::
VPF(S) := 1
| V3(@S) -E- 2 ::
VPF(S) := 2
29
| V3(@S) -E- 3
::
VPF(S) := 1 -U- 2
:)
:)
| V2(S) -NE- V20 -ET- $PCIS2(S,@S)
-OU- UL(@S) -E- 'ULCOPL1'
::
$PAF2(S) , VPFX(S) := VPFX(S) -U- 4 , UL(S) := 'ULEXP1'
| ::
:)
-FIN-
Fichiers des formats sources et cibles.
On a gardé l'organisation du LSPL TRANSF. Les formats sources prenant leurs valeurs dans le jeu de décorations 1, les
formats cibles prenant leurs valeurs dans le jeu de décorations 2, ne posent donc aucun problème particulier. Un nom de
format peut être commun à un format source et à un format cible. On considère qu'à un format est associé un type relatif au
jeu 1 ou 2. Celui-ci sera pris en compte au niveau du métalangage de façon semblable à un type associé à un code origine.
Ces formats, aussi bien sources que cibles, peuvent comporter des valeurs d'UL.
Exemple de formats sources:
FORB1
FORB2
FORB3
01==.** VPE1 -E- 1.
01==.** VPC -E- 1.
01==.** VPB1 -E- 1.
Exemple de formats cibles:
FORA1
FORA2
FORA3
01==.** VPC -E- 1.
01==.** VPFX -E- 1.
01==.** VPF -E- 1.
Définitions de procédures.
Les procédures, référençables à partir des différents dictionnaires ont leurs définitions, comme pour le LSPL TRANSF,
regroupées en un seul fichier. Le formalisme général de définition de ces procédures correspond à ce qui a été exposé au
chapitre V et dans les diagrammes (II.1), à (II.9). Par rapport au LSPL TRANSF, on note l'apparition des procédures
réseaux, le regroupement de toutes les procédures d'étiquettes qui doivent être précédées d'un indicateur "PCP", "PAF" ou
"PCIS". La présence des procédures de conditions intersommets est une nouveauté par rapport à TRANSF. Le formalisme
est donc homogène à celui qui a été adopté pour le LSPL ROBRA.
On notera que les procédures de conditions propres et de conditions intersommets jouent désormais un rôle symétrique. Une
procédure de conditions propres et une procédure de conditions intersommets peuvent porter le même nom. Une procédure
de conditions propres peut être appelée à l'intérieur d'un réseau d'affectations conditionnelles (ou d'une procédure réseau).
L'élément du contexte correspondant doit être passé en paramètre. C'est le nombre d'arguments qui permet de distinguer un
30
appel de procédure de conditions propres, d'un appel de procédure de conditions intersommets (qui comporte toujours au
moins un argument). L'argument passé en paramètre peut être du type "@X", "çX" ou "X". Ce type doit être acceptable par
la procédure appelée.
Exemple:
-PROC** (J1,J1).
PCIS:
PCISF(X,Y) == VPAX1(X) -E- VPAX10 -OU- VPAX1(Y) -E- 1.
** (J1,J2,J12).
PCIS:
PCISJ(X,Y,Z) == VPE1(X) -I- VPC(Z) -E- VPFX(Y) -I- V3(Z).
** (J2,J1,J12).
PCIS:
PCISH(X,Y,Z) == VPFX(X) -I- VPC(Z) -E- VPE1(Y) -I- V3(Z).
** (J12,J12,J2).
PCIS: PCISEX(X,Y,Z) == V2(X) -I- V2(Y) -NE- V20 -ETV3(X) -I- VPC(Y) -I- VPFX(Z) -NE- V30.
** -J12- .
PCP: PCP1 == VPC -E- 1 .
** -J12- .
PCP: PCP2 == VPC -E- 2 .
** -J2- .
PAF: PAF2 == 'LULU' .
31
** -J2- ; (J2,J1,J2) .
PAF:
PAF1(X,@Y,çZ) == UL := UL(X) , VPC := VPC(@Y) , V3 := V3(çZ).
** (J12,J12,J12) .
PCIS:
PCISE(X,Y,Z) == VPC(X) -I- VPC(Y) -E- VPC(Z) -I- VPC(Y).
** (J12,J1) .
PCIS: PCISC(X,@Y) == UL(@Y) -E- UL(X) .
** (J12,J12) .
PCIS: PCISA(X,Y) == UL(X) -E- UL(Y).
** (J1,J2) .
PCIS: PCISB(@X,çY) == UL(@X) -E- UL(çY).
** (J2,J12) .
PCIS: PCISD(çX,Y) == UL(Y) -E- UL(çX).
** (J2,J2) .
PCIS: PCISG(X,Y) == VPEX(X) -E- 1 -OU- VPEX(Y) -E- 1.
-PRCA** (;J1,J12,J2,J2) .
32
PRCA1(A,B;C,D,E,çF) ==
(:
$PCISE(C,C,D) -OU- VPC(C) -E- VPC(D)
::
VPC(A) := VPC(C)
|
:: $PAF2(A) , $PAF1(B;çE,@C,çF) , VPC(B) := VPC(D)
:).
** (;J2,J12,J2) .
PRCA2(A;B,C,@D,çE) == (: $PCISA(@D,çE) :: $PAF2(A)
|
:: $PAF1(A;B,@D,çE)
:).
-FIN-
Dictionnaires généraux (de 1 à 7).
Ces dictionnaires se présentent également comme des extensions des dictionnaires du LSPL TRANSF. Chaque dictionnaire
est constitué par une suite d'articles. Chaque article d'un même dictionnaire correspond à une valeur d'Unité Lexicale source
distincte. L'article est une suite de "triplets" comportant une condition de sélection et une partie transformation. Cette partie
transformation se décompose en arborescence image (si elle est vide, l'image est réduite à un sommet unique) et affectation
dont la forme générale est celle d'un réseau d'affectations conditionnelles. Le dernier triplet d'un article ne peut comporter
de condition de sélection, ce qui garantit, dans tous les cas, la prise en compte d'un triplet de l'article (<ARTDIEX> (III.4) ).
Les valeurs d'UL sont notées comme en ROBRA, c'est-à-dire entre deux caractères ' (on double un ' interne).
La partie condition porte sur les valeurs d'étiquette d'un contexte source "figé" (et donc, non géométriquement exprimé dans
le triplet), constitué par la sous-arborescence source composée du sommet courant "(@S)", de son père "(@P)", de son frère
gauche "(@G)", et de son frère droit "(@D)". Si l'un des trois derniers sommets n'existe pas, on lui associe la valeur
d'étiquette nulle. La condition s'exprime par une condition intersommets ("@S" est une origine par défaut), avec appels
internes possibles, à des procédures de conditions intersommets ou procédures de conditions propres. Cette condition
intersommets peut se réduire à une condition propre (portant sur l'origine implicite "@S"), ou à un appel de procédure de
condition propre, ce qui permet de retrouver la compatibilité avec TRANSF.
La partie arborescence transformée garde les conventions du LSPL TRANSF. Elle comporte, soit une arborescence explicite
(arborescence image), soit elle est vide, auquel cas l'image est un unique sommet de nom "S".
La dernière partie du triplet exprime le calcul des valeurs d'étiquettes associées à l'arborescence transformée, sous la forme
générale d'un réseau d'affectations conditionnelles. Ce réseau peut comporter des appels à des procédures réseaux, ou des
procédures d'étiquettes, définies dans le fichier des procédures. Son contexte intègre:
- le contexte source "@S", "@P", "@G", "@D" (non modifiable),
- les valeurs initiales d'étiquettes (dans le jeu 2), associées à l'arborescence, après application de TRACOMPL
à partir de "@S". Si "d" est un identificateur de sommet de l'arborescence image, ces valeurs initiales (non
modifiables), sont désignées par "çd",
33
- les valeurs d'étiquettes courantes (dans le jeu 2), qui deviendront les valeurs finales associées à l'arborescence
image ("d").
Si l'arborescence n'est pas explicitée, on utilisera, dans le réseau, les codes origines: "@S", "çS" et "S".
Chaque sommet de l'arborescence image se voit initialement (avant le prise en compte de la partie affectation du triplet)
affecté d'une même valeur d'étiquette, calculée par application du LSPL "TRACOMPL" intégré sur "@S".
Dans le LSPL EXPANS en mode monolingue cette valeur d'étiquette recouvre la valeur d'UL cible, qui est donc celle de
l'UL source (sommet courant "@S" source). Dans le LSPL EXPANS en mode bilingue, cette valeur d'étiquette ne recouvre
pas la valeur d'UL cible, il y a obligation d'expliciter cette affectation pour tous les sommets de l'arborescence image. Cela
se traduit par la prise en compte de propriétés de cohérence au niveau des réseaux d'affectations conditionnelles, analogues à
celles présentées pour ROBRA dans le DSE-1 (DSE-1 3-3.3.5.3), mais relatives, ici, aux affectations d'UL cibles. On notera
l'utilisation possible à l'intérieur d'un réseau d'affectations conditionnelles du formalisme:
'<valeur_d'UL_cible>', pour
UL := '<valeur_d'UL_cible>',
lorsque le code origine est prédéterminé (c'est-à-dire après une affectation globale). L'introduction de cette convention
rejoint celles prises pour décrire le niveau principal d'affectations (traité, en fait, comme un réseau dégénéré en une branche
unique inconditionnelle), où des considérations de compatibilité avec le LSPL TRANSF doivent intervenir. C'est ainsi que
si ce niveau comporte un réseau à fonctionnement non déterministe, non applicable, on ne remet pas en cause les
affectations du niveau principal, mais on ignore simplement ce réseau.
A ce niveau, on retrouve la notion de listes d'affectations, chaque élément de cette liste étant relatif à un sommet de
l'arborescence image (<AFREG> (IV.9) ). Chaque affectation est constituée d'une "affectation globale" (<AFGL> (IV.6) ),
suivie d'un complément d'affectations éventuellement vide (<EXPC> (IV.7) ).
Des appels de procédure réseau et des réseaux d'affectations conditionnelles peuvent désormais figurer dans ce niveau
principal d'affectations. On retrouvera donc, dans les dictionnaires du LSPL EXPANS en mode bilingue (au niveau
<AFGL>), des séquences d'affectations analogues à celles de TRANSF ((1) DSE1 E.III.4.2):
<orig> : 'ULj2' , *<format>
ou <orig> : 'ULj2' , +<format>
ou <orig> : 'ULj2' ...
Pour les dictionnaires du LSPL EXPANS en mode monolingue, 'ULj2' n'est pas obligatoire, la partie affectation peut donc
éventuellement être vide.
La signification de "*" et "+", devant <format> reste la même que pour TRANSF:
"*" -> introduction de la totalité de la valeur d'étiquette associée au format (à l'exclusion de la valeur d'UL),
"+" -> introduction des valeurs d'étiquettes associées au format correspondant à des variables créées dans le
jeu cible.
Exemple:
'*'
.
==
/
34
/'UL0'
'A'
/
.
'B'
/
.
'C'
==$PCISF(@P,@S) /A(B) /A:'*A1';B:'*A2'
==$PCP1
/
/'*A'
/
/'*B'
/
/'**B'
== VPC(@P)-I-VPC(@G)-E-VPC(@D)-I-VPC(@S)
/
/'*C1'
/
//'*C2',$$PRCA2(S;çS,çS,@P,çS).
'D'
==
/'*D'çS,$PAF1(S,@P,çS),
/
(: VPC(@P) -E- VPC(@D)
::
*S:çS,'**D1'
|
UL(S) :=
VPC(@G) -E- VPC(çS) ::
'**D2', VPC(S) := VPC(çS) -I-
VPC(@P),
$PAF1(S;S,@S,çS)
:).
'E'
== $PCP1 /A(B)
/
(: $PCISJ(@S,çA,çB) ::
*A:A , '*E1',
VPC := 1
;
*B:çB , '*E2' , VPC := 2
|
$PCISF(@S,@P)
::
*A:A , '*E3' , VPC := 2
;
*B:+FORA1 , '*E4' ,
$$PRCA2(A;B,B,@S,çA)
:)
/
$PCP2 /A(B)
/
(: VPC(@S) -E- 1
::
35
*A:çA , '*E5' ,$PAF1(A;B,@P,çB)
;
*B:çB , '*E6' ,$PAF2(B)
|
VPC(@S) -E- 2
::
*A:*FORA1 , '*E7' , $PAF2(B)
;
*B:çB
, '*E8' , $PAF2(A)
,
$$PRCA2(B;A,B,@P,çB)
:)/
/
/'E9'
.
'F'
.
'G'
.
'H'
.
'I'
.
'ULTXT'
.
'ULFRA'
.
'ULOCC'
.
==
/
/'*F'
==
/
/'*G'
==
/
/'*H'
==
/
/'*I'
==
/
/'*ULTXT' çS
==
/
/'*ULFRA',VPC := VPC(@S)
==
/
/'*ULOCC',+FORA1
'ULMCP'
/
==$PCP2
/
/'*ULMCP' S
$PCP1/A(B,C)/A:'*ULMCP1',*FORA1,$PAF2
;
B:'*ULMCP2',*FORA2
;
C:'*ULMCP3',+FORA3
/
/
.
'ULSOL'
.
'UL0'
.
'*ULMCP' çS,VPC := VPC(S)
==
/
/'*ULSOL',*FORA2
==
/
/'UL0'
36
Dictionnaire zéro.
Ce dictionnaire regroupe les articles correspondant à des cas particuliers du traitement, et aucun d'entre eux n'est adressé
directement par une valeur d'UL source. Un premier ensemble, constitué de zéro à huit (au maximum) triplets est destiné à
la description de l'action par défaut, effectuée lorsqu'aucune entrée des dictionnaires généraux n'est utilisable. Le neuvième
triplet décrit l'affectation du sommet racine multidictionnaire. Le dixième triplet est associé à la prise en compte de la valeur
d'UL source particulière qu'est la valeur zéro ("UL0").
a) Les triplets d'action par défaut.
Une action par défaut est effectuée lorsque, pour un sommet source courant, aucun article des dictionnaires généraux ne
peut convenir. Le numéro du triplet choisi pour cette action, est passé en paramètre pour une exécution. Un tel triplet ne
peut comporter de partie condition, la partie arborescence doit également être vide (<ARTDIEX0> (III.1) ). Par contre, il
pourra comporter, en partie affectation, une première composante relative à une expression d'affectation de valeur chaîne
d'UL (<AFUL> (III.6) ), suivie d'une seconde composante constituée par un réseau d'affectations conditionnelles identique à
celui que l'on peut trouver dans un triplet normal (<AFREG> (IV.9) ). L'expression d'affectation de valeur chaîne d'UL est
une concaténation de chaînes constituées, soit par des valeurs de chaînes explicites (entre ' ), soit par la valeur de chaîne de
l'UL source (désignateur "UL"). L'opérateur de concaténation est "||". Le réseau complémentaire utilise les codes origines:
"@S", "çS" et "S".
Exemple de triplet d'action par défaut:
==
/
/ 'A1' || UL || 'Z2' || UL .
b) Le triplet prise en compte de la racine multidictionnaire.
Il est également inconditionnel, ne peut comporter de partie arborescence, mais intègre un réseau d'affectations
conditionnelles dont le contexte source est constitué par les divers sommets correspondant aux racines des arborescences
images obtenues à partir des différents dictionnaires, son contexte cible est le sommet racine "(S)". Les éléments du
contexte source sont repérés par le numéro du dictionnaire dont ils proviennent. Pour le dictionnaire numéro "i", on utilise
"(i)" pour désigner la racine correspondante. Si cette racine n'existe pas, il lui est associé la valeur d'étiquette nulle
(<ARTDIRAC (III.3) ).
Exemple de triplet racine multidictionnaire.
==
/
/ , 'UL0', V2 := V2(2), UL := '**B',
(: V2(1) -E- 7 :: *S:*FORA, V2 := V2(1) | ::
*S:*FORA2, V2 := V2(2) :).
c) Le triplet associé à "UL0".
Il est inconditionnel, peut comporter une arborescence, ainsi qu'une partie affectation avec un réseau (<ARTDIUL0> (III.2)
).
Si l'un des deux derniers articles figure, les huit premiers triplets doivent figurer dans le dictionnaire. Ils peuvent être réduits
à la simple expression:
==
/
/
/
.
37
CARTES SYNTAXIQUES.
Syntaxe.
Les cartes suivantes présentent la syntaxe (hors-contexte) des LSPL TRACOMPL et EXPANS (sous ses deux modes). Les
unités syntaxiques non terminales sont désignées par un nom en majuscules, les unités syntaxiques terminales par un nom
en minuscules, ces noms étant placés entre "<" et ">".
On a choisi de présenter la grammaire sous forme de diagrammes de Floyd augmentés, comme cela a déjà été fait pour le
DSE1 ((1) DSE1 D.V.1).
Les syntagmes terminaux sont désignés par un symbole précisant la catégorie à laquelle ils appartiennent. Par exemple
"id(n)" désigne un identificateur de "n" caractères au maximum, "litt." une valeur littérale, "entier" une valeur entière, etc ...
Ces conventions s'appliquent à l'ensemble des métalangages des différents LSPL d'ARIANE-78 et G5. Les aspects
sémantiques principaux figurent sous forme de notes accompagnant les diagrammes.
Graphe de dépendances des unités syntaxiques.
Pour une utilisation commode des cartes syntaxiques, on présente le graphe de dépendances des principales unités
syntaxiques. Ces unités se répartissent entre les quatre composantes:
a) déclarations de variables,
b) définition des procédures,
c) dictionnaires,
d) tronc commun.
Commentaires.
Pour les composantes: déclarations de variables et définitions de procédures en TRACOMPL et en EXPANS, les
conventions relatives à l'utilisation des commentaires sont celles des grammaires ROBRA. Le format des données est libre,
les commentaires peuvent figurer à n'importe quel endroit (intérieur d'une valeur littérale exclu). Un commentaire est
délimité à gauche par "**" et se termine avec le premier "." rencontré. Une séquence "***" est interprétée comme le
caractère "*", suivi d'un commentaire, une séquence de plus de trois "*" successives est illégale.
Les conventions concernant l'usage des commentaires dans les formats du LSPL EXPANS sont celles des formats des
autres LSPL: présence possible d'un commentaire entre "==" et "." de la définition de format. Dans le cas des dictionnaires
EXPANS, un commentaire peut prendre place partout dans un article, après le séparateur "==" qui suit le nom d'UL source.
Syntaxe de la partie déclarations de variables.
I.1 - <DECVAR> : Déclaration des variables.
(A) - si phase autre que SYGMOR.
(B) - uniquement si phases TRACOMPL, TRANSFER ou EXPANS.
<alpha> - <bêta> - <gamma> : trois caractères servant aux noms de variables générales implicites.
(EOF) désigne la fin de fichier.
38
I.2 - <ELDEX> : Elément de déclaration des variables.
(A) - nom de variable (id(7)) jeu no.1 (source).
(B) - nom de variable (id(7)) jeu no.1 et no.2 (source et cible).
(C) - nom de variable (id(7)) jeu no.2 (cible).
(D) - uniquement si non sous portée de "$".
(E) - uniquement si phase biétiquetée.
- Note - Il doit y avoir concordance du choix du type de séparateur ":=(" ou "==(" pour l'ensemble du fichier de déclarations
de variables.
I.3 - <DICT> : déclaration de la variable dictionnaires (phase ATEF).
(A) entier de 1 à 6.
- Note - DICT doit figurer parmi les variables non exclusives.
I.4 - <VAVEX> : Partie droite de l'élément de déclarations de variables.
(A) - interdit sous portée de "$" ou "$$".
(C) - obligatoire si on est passé par (B).
(D) - plus autorisé dans aucune phase en version 5 (gardé pour compatibilité avec version 4).
(E) - <nom_de_valeur>: (id(8)) doit être différent de <nom_de_variable>0.
(F) - valeur arithmétique (entier positif).
Syntaxe des définitions de procédures.
II.1 - <FIPROC> : Fichier des déclarations de procédures.
(EOF) désigne la fin de fichier.
II.2 - <DPROC> : Définition des procédures.
II.3 - <PROCET> : Définition des procédures d'étiquette.
II.4 - <LDPROCET> : Liste de définition des procédures d'étiquette.
II.5 - <DPCIS> : Définition de procédures de conditions intersommets.
(A) - nom de procédure de condition intersommets (id(8)), peut être identique à un nom de procédure de condition propre.
(B) - nom de paramètre (id(8)), substituable par un code origine source ou cible.
(C) - nom de paramètre (id(8)), substituable par un code origine source.
(D) - nom de paramètre (id(8)), substituable par un code origine cible.
39
(E) - l'expression ne peut être vide, les codes origines correspondent aux paramètres de la procédure.
- Note - Le nombre de paramètres doit être supérieur ou égal à un.
II.6 - <DPCP> : Définition de procédure de condition propre.
(A) - nom de procédure de condition propre (id(8)), peut être identique à un nom de procédure de condition intersommets.
(B) - l'expression ne peut être vide, il n'y a pas de codes origines (ils sont prédéterminés.)
II.7 - <DPAF> : Définition de procédure d'affectations.
(A) - nom de procédure d'affectation (id(8)), doit être unique dans l'ensemble des noms de procédures d'étiquettes.
(B) - nom de paramètre (id(8)), substituable par un code origine source ou cible.
(C) - nom de paramètre (id(8)), substituable par un code origine source.
(D) - nom de paramètre (id(8)), substituable par un code origine cible.
(E) - expression d'affectation simple qui ne peut être vide.
- Note - On peut avoir n (n entier positif ou nul) paramètres, selon le contexte l'appel se fera avec n ou n+1 paramètres.
II.8 - <LDPRCA> : Liste de définition de procédures RCA.
II.9 - <DPRCA> : Définition de procédure réseau.
(A) - nom de procédure réseau (id(8)), doit être unique pour l'ensemble des noms des procédures réseaux.
(B) - nom de paramètre (id(8)), substituable par un code origine cible (un ou plusieurs tels paramètres).
(C) - nom de paramètre (id(8)), substituable par un code origine source ou cible.
(D) - nom de paramètre (id(8)), substituable par un code origine source.
(E) - nom de paramètre (id(8)), substituable par un code origine cible.
(F) - réseau sous forme RESAS1 ou RESAS2 (se distinguent par le choix des marquants).
Syntaxe des dictionnaires EXPANS.
Rappelons que les articles des dictionnaires dont on présente la syntaxe concernant la partie "format libre", s'insèrent dans
un fichier formaté où l'on trouve pour chaque article la valeur d'UL source suivie de "==", en tête de cet article.
III.1 - <ARTDIEX0> : Article pour le dictionnaire numéro zéro (huit triplets de rattrapage).
III.2 - <ARTDIUL0> : Article associé à UL0.
III.3 - <ARTDIRAC> : Article pour calcul de l'étiquette de la racine multidictionnaire.
III.4 - <ARTDIEX> : Article dictionnaire (forme générale).
(A) - valeur d'UL source en EXPANS mode bilingue (litt.) ou valeur d'UL source ou cible en EXPANS mode monolingue
(litt.).
40
III.5 - <ARBOR> : Arborescence transformée.
(A) - identificateur de sommet (id(8)), doit être unique pour l'arborescence qui ne peut comporter plus de 64 sommets.
III.6 - <AFUL> : Expression d'affectation d'UL chaîne.
(A) - "UL" désigne la valeur chaîne d'UL source du sommet S (@S).
(B) - valeur littérale.
Syntaxe de la partie commune.
IV.1 - <RESAS1> : Réseau d'affectations conditionnelles (forme 1).
IV.2 - <RESAS2> : Réseau d'affectations conditionnelles (forme 2).
IV.3 - <ACOND> : Partie condition en réseau.
IV.4 - <AFREZ> : Partie affectation en réseau.
IV.5 - <APRORCA> : Appel de procédure réseau.
(A) - origine cible (id(8)).
(B) - origine source (id(8)).
(C) - origine source ou cible (id(8)).
(D) - nom de procédure réseau (id(8)). Doit être unique dans l'ensemble des noms de procédures réseaux. Il doit y avoir
concordance du nombre des paramètres avec celui de la définition de procédure réseau.
IV.6 - <AFGL> : Affectation globale.
(A) - uniquement si:
- dictionnaire d'EXPANS en mode bilingue ou monolingue et,
- pas d'arborescence dans le triplet et,
- affectation globale de niveau zéro.
(B) - uniquement si:
- dictionnaire d'EXPANS en mode bilingue ou monolingue et,
- affectation globale de niveau zéro.
(C) - uniquement si (B) et,
- dictionnaire EXPANS en mode monolingue
(D) - uniquement si:
- non dictionnaire d'EXPANS en mode bilingue ou monolingue ou,
41
- non affectation globale de niveau zéro.
(E) - origine cible (id(8)).
(F) - origine source ou cible (id(8)).
(G) - valeur d'UL (litt.),
- jeu cible pour EXPANS en mode bilingue,
- jeu source ou cible pour EXPANS en mode monolingue.
(H) - nom de format (id(8)) cible (jeu no.2).
(I) - par détection de "," ou ";" ou "/" ou ".".
(I') - par détection de "," et non ",*" ou ";" ou "/" ou ".".
(J) - non licite en partie "-CVAR-".
IV.7 - <EXPC> : Complément d'affectations.
IV.8 - <APROCAF> : Appel de procédure d'affectation.
(A) - nom de procédure d'affectation.
(B) - uniquement si non en réseau.
(C) - uniquement en réseau.
(D) - origine cible (id(8)).
(E) - origine source (id(8)).
(F) - origine source ou cible (id(8)).
- Note - Il doit y avoir concordance du nombre de paramètres (+1 si l'on passe par (C)) avec celui de la définition de
procédure d'affectations.
IV.9 - <AFREG> : Affectation.
(A) - sauf si dictionnaire d'EXPANS en mode bilingue ou monolingue et pas d'arborescence.
IV.10 - <AFECT> : Expression d'affectation.
(A) - uniquement si variable exclusive.
(B) - uniquement si variable non exclusive ou arithmétique.
(C) - uniquement lorsque l'origine est prédéterminée (abréviation pour "UL:='ULj2'").
(D) - valeur d'UL (litt.)
- jeu cible en EXPANS mode bilingue,
- jeu source et cible en EXPANS mode monolingue.
42
IV.11 - <APROCIS> : Appel de procédure de condition.
(A) - nom de procédure de condition propre ou intersommets.
(B) - uniquement pour une procédure de condition propre.
(C) - origine source (id(8)).
(D) - origine cible (id(8)).
(E) - origine source ou cible (id(8)).
- Note - zéro ou un paramètre implique une procédure de condition propre, plus d'un paramètre implique une procédure de
condition intersommets. Le nombre de paramètres doit alors coïncider avec celui de la définition de procédure.
iv.12 - <EXBOOL> : Expression booléenne.
IV.13 - <TSTET> : Niveau ET.
IV.14 - <EXBOOL2> : Niveau N.
IV.15 - <RELAT> : Relation.
(A) - uniquement si unité de type arithmétique.
(B) - uniquement si variable non exclusive.
IV.16 - <TSUNI> : Niveau U.
(A) - uniquement si unité arithmétique.
(B) - uniquement si unité non exclusive.
IV.17 - <TSINT> : Niveau I.
(A) - uniquement si unité exclusive.
(B) - uniquement si unité arithmétique ou non exclusive.
(C) - uniquement si unité arithmétique.
(D) - uniquement si unité non exclusive.
IV.18 - <EL2> : Elément 2.
(A) - uniquement si élément arithmétique.
(B) - invalide si élément arithmétique.
IV.19 - <OPER> : Opérande.
(A) - unité de type arithmétique et non premier opérande de cette unité.
(B) - unité de type "UL" et non premier opérande de cette unité.
43
(C) - unité de type non arithmétique et non "UL" et non premier opérande de cet élément.
(D) - nom de format (id(8)) jeu source ou cible.
(E) - code origine source (id(8)).
(F) - code origine cible (id(8)).
(G) - code origine source ou cible (id(8)).
(H) - valeur d'UL (litt.).
(I) - non licite en partie "-CVAR-".
CONCLUSION.
Pour l'utilisateur du système ARIANE, désirant faire évoluer ses applications ARIANE-78 vers ARIANE-G5, il est
conseillé de procéder en deux étapes. La première consistera à reprendre ses applications dans leur état ARIANE-78, sans
modifier leur organisation générale. Moyennant quelques modifications syntaxiques indispensables, mais très limitées,
touchant les déclarations de variables, et les procédures TRANSF, on obtient la compatibilité entre ces deux versions (7).
Dans une seconde étape, on pourra, si on le désire, refondre les applications pour mettre pleinement à profit les possibilités
nouvelles offertes par ARIANE-G5, concernant l'organisation globale des données lexicales, l'introduction de nouvelles
phases, l'extension des LSPL et la possibilité de créer un grand nombre de variantes à partir d'un même linguiciel
(multiplicité des chaînes d'exécution et variantes pour chaque phase).
DOCUMENTS REFERENCES.
(1) Le point sur ARIANE 78 début 1982 (DSE-1) - Partie I : le logiciel.
GETA - CHAMPOLLION / CAP SOGETI FRANCE. Avril 1982.
Contrat ADI (252 pages).
(2) ARIANE-78 version 5 - Transformations à apporter à ARIANE-78 en vue du projet ESOPE.
Ch.BOITET - 22/09/82.
Note interne GETA (10 pages).
(3) Les langages des modèles de la version 5 d'Ariane 78.
P.GUILLAUME - 26/02/85.
Document interne GETA (69 pages).
(4) ARIANE 78.5, modèle EXPANS, mode de fonctionnement multidictionnaire.
Note interne GETA (18 pages).
(5) ARIANE-G5, les modèles TRACOMPL, EXPANS et TRANSFERT.
Document interne GETA (90 pages).
(6) A case study in software evolution: from ARIANE-78 to ARIANE-85.
Ch.BOITET P.GUILLAUME M.QUEZEL-AMBRUNAZ - August 85.
Proc. of the Conf. on theoretical and methodological issues in Machine Translation of natural languages, 27-58, Colgate
Univ., Hamilton, N.Y.
44
(7) ARIANE-78 vers ARIANE-G5.
M.QUEZEL-AMBRUNAZ - Mai 89.
Publication GETA (9 pages).
45

ARIANE-G5 : Les langages spécialisés TRACOMPL et EXPANS.

Transcription

Documents pareils

D\351penses et affectations du budget 2012.xls

zet de uitdrukkingen bij de juiste plaatjes - Arti-Choc

déclaration de porte

Fabrications : Le thé tre du quotidien

26 ans, Célibataire

LETTRE DE RECLAMATION DES SOMMES DUES AU DECES

Voyelles A noir, E blanc, I rouge, U vert, O bleu

Diapositive 1

Pouvoir - Chambres de Métiers et de l`Artisanat des Yvelines

la gestion administrative et comptable de votre filiale au royaume-uni