arbre syntaxique decrit la structure d`une forme.

Transcription

NOTIONS SUR LA TRADUCTION
1 ) Notions de base
1.1 - compilation d’un texte : plusieurs phases ……………. 2
1.2 - vocabulaire et grammaire d’un langage …………….…3
1.3 - grammaire : définition et utilisations ………………… 4
1.4 - reconnaissance : arbre syntaxique ……………………. 5
2 ) Introduction à l’analyse lexicale
2.1 - fonction …………………….………………………... 6
2.2 - définition d’un vocabulaire ………………………….. 7
2.3 - expressions régulières : principes ……………………. 8
2.4 - expressions régulières : autres possibilités …………... 9
10/04/12
Télécom SudParis – CSC 4508 – Notions sur la Traduction
1
1.1 – Compilation d'un texte : PLUSIEURS PHASES
Café
0.2€
0.2€
Ex1.1.1
Stop
Stop
Stop
Texte en entrée
OK
("mots")
Analyse LEXICALE
? unités lexicales ou "mots" appartiennent
au VOCABULAIRE du langage L ?
OK
Analyse SYNTAXIQUE
int t[ ]={0,1,2}, i;
for(i=0;i<3;i++) {
t[i] *= 2;
}
("phrases" ou "formes")
? unités lexicales arrangées selon les
FORMES SYNTAXIQUES de L ?
OK
ACTIONS
Analyse SEMANTIQUE ("sens")
Interpréter les conventions sémantiques s'il y en a
GENERATION de CODE
"Interprétation":
actions immédiates
10/04/12
Ex1.1.2
Compilation:
préparer un CODE EXECUTABLE plus tard
2
1.2 – VOCABULAIRE, GRAMMAIRE d'un langage L
Vocabulaire
unités lexicales possibles ("mots") du langage cible L
- un vocabulaire fini peut être défini par énumération => Voir Ex1.2.1
- d'autres méthodes permettent des vocabulaires infinis => Voir 2 - Analyse Lexicale
Règles syntaxiques
constructions possibles pour grouper les u. lexicales
Ex1.2.1 : grammaire d'un langage naturel élémentaire
Catégories lexicales Valeurs possibles
Reconnaît (mal) 1 sous-titre
du Wall Street Journal … !
Sera complété !
partie => les "mots" possibles dans L
<DOT>
:= ‘.’
lexicale = le " vocabulaire terminal " VT
<ART>
:= a | an | the
<TRANS_VRB> := cut | cuts
- définitions (éventuellement
partie
syntaxique récursives) des formes possibles
<COMM_NOUN> := bill | bills
- en fonction d'autres symboles,
<PROP_NOUN> := Bell | Verizon
ou de catégories lexicales
<Sentence>
:= <SubjVrbCplt> <DOT>
<SubjVrbCplt>:= <NounGrp> <TRANS_VRB> <NounGrp>
<NounGrp> := <PROP_NOUN> | <ART> <COMM_NOUN>
<xxx> : symboles de VN, Vocabulaire Non-Terminal de la grammaire
10/04/12
3
1.3 - GRAMMAIRES : DEFINITION, UTILISATION
Grammaire G
(VT,VN,P, S)
VT vocabulaire terminal
VN vocabulaire non terminal
P règles syntaxiques
S axiome ou "start symbol"
Une règle syntaxique :
Tête (Left Hand Side, LHS) :
définit un symbole non terminal
<NTh > :
EX.1.3.1
les mots du langage L
définissent les notions de la grammaire
ou "règles de production", voir + bas
le symbole de VN défini d'après les autres,
mais ne servant pas à en définir d'autres
Queue (Right Hand Side, RHS) :
- un ensemble OU d' alternatives
- chacune: concaténation ET de symboles de VT ou VN
(alternative vide possible)
| <NTi > <Tj >
| <Tk > <NTl > <Tm >
;
(marque de fin de règle)
Utilisations :
a) en "production" de formes : par substitutions partie gauche / partie droite
< SubjVrbCplt> <DOT>
<Sentence>
(suite Ex.1.2) <NounGrp> <TRANS_VRB> <NounGrp> <DOT>
EX.1.3.2
b) en reconnaissance (parsing)
par réductions (remplacements RHS->LHS)
10/04/12
Bell cut Verizon .
= une production syntaxiquement correcte
Voir => Analyse syntaxique
4
1.4 - Reconnaissance : ARBRE SYNTAXIQUE
décrit la structure - pouvant être produite par la grammaire
d'une forme
- reconnue dans l'entrée par réductions
successives (remplacements RHS ->LHS)
= arbre étiqueté
- feuille : unité lexicale reconnue ("mot", un symbole de VT)
- nœud : tête de la règle appliquée pour réduire (symbole de VN)
<Sentence>
EX.1.4
(suite Ex.1.2)
< SubjVrbCplt >
<DOT>
<NounGrp>
<NounGrp>
<PROP_NOUN> <TRANS_VRB> <ART> <COMM_NOUN>
Texte en entrée :
Verizon
cuts
the
bills
.
Cette grammaire est très élémentaire :
- accepte 1 seule forme possible pour <Sentence>
- accepte l'entrée ssi formée d'1 seule <Sentence>
Verizon cut the bills .
- accepte d'autres entrées
syntaxiquement correctes Verizon cuts an bill .
the bill cuts Verizon .
mais dénuées de sens
10/04/12
besoin de grammaire + élaborée
(élimination possible
par analyse sémantique)
5
2.1 - INTRODUCTION A L'ANALYSE LEXICALE
ROLE - reconnaître les unités lexicales, ou "tokens", ou "mots"
- et leurs catégories lexicales nécessaires pour l' analyse syntaxique
EX.2.1 ( = Ex.1.2, légèrement complété)
PRINCIPE
- du texte en entrée …
- … dériver une chaine prétraitée
de 2-uples: catégorie lexicale
no dans la catégorie
catégorie
- et les structures auxiliaires
0
Verizon , Bell South will cut the DSL bills .
2
1
1
'.' ','
1
(0)
2
0
2
PROP_NOUN
0 Bell
1 Verizon
2
2
3
0
3
AUX
4
0
5 6
0 2
4
TRANS_VERB
0 will
0 cut
1 cuts
6
1
5
ART
0 the
0
(0)
6
COMM_NOUN
0 bill
1 bills
2 DSL
IMPLEMENTATION pratique. Exemple : avec les outils “flex” / “bison”
- l’analyseur syntaxique demande
quand il en a besoin la prochaine
unité lexicale (″look-ahead″)
- l'analyseur lexical retourne
la catégorie lexicale (et passe
éventuellement la valeur)
10/04/12
fonction yyparse( )
…
fonction yylex( )
…
préparé
avec "bison"
préparé
aec "flex"
Voir =>
Linux Tools:
flex, bison
6
2.2 - DEFINITION DU VOCABULAIRE TERMINAL
PRINCIPE
mots (=unités lexicales) : formés par concaténation
de symboles élémentaires ou "caractères"
pris dans un alphabet
3 POSSIBILITES
1) Définition par énumération
EX.2.2.1
<Séparateur> : ‘,’ | ‘.’ | ‘:’ | ‘;’ ;
<Opérateur> : ‘+’ | ‘-’ | ‘*’ | ‘/’ ;
- vocabulaire limité, statique
- techniques : . tables, dictionnaires
. énumération dans des règles de production "plates"
2) Définition par règles de production récursives
- le vocabulaire peut être infini
EX.2.2.2
3) Définition par "expressions régulières"
- formalisme + simple, possibilités + limitées
- peut aussi définir un vocabulaire infini
10/04/12
<Nom>
;
<Entier>
: <Lettre>
| <Nom > <Lettre>
: <Chiffre>
| <Entier > <Chiffre>
;
<Lettre> : ‘A’ | ‘B’ | …..
<Chiffre> : ‘0’ | ‘1’ | …..
;
;
Voir => 2.3 - Expressions régulières
7
2.3 - EXPRESSIONS REGULIERES (E.R.) , 1 : PRINCIPES
PRESENTATION
- formalisme + limité que les règles de production générales :
. = une utilisation particulière des règles de production
. correspondent aux automates à états finis
Voir => Grammaires
Voir => Automates
- suffisant pour analyse lexicale de langages simples :
langage de commandes, utilitaires de "filtrage" (Linux, Java…) …
UTILISATION
a) spécification d’une e.r. :
opérateurs et métacaractères
b) reconnaissance d’e.r. :
par interpréteur (applique
l’automate correspondant)
Caractères spéciaux fondamentaux
.
un symbole quelconque
(implicite) concaténation ET
| alternative OU
* répétition N fois, N ≥ 0
+ répétition N fois, N > 0
( ) délimiteurs de groupement
Ex.2.3
alphabet de base : { a, b, c }
e.r. :
a+(b|c)*a*
caractérise un ensemble infini de mots :
10/04/12
a
aaa
ab
aba
abbb
abbba
abcbcba
…
Souvent : sauf \n
opérateurs
- chaînes sur {a,b,c}
- commençant par au moins un a
- suivi(s) de b ou c
en nombre quelconque
- éventuellement terminée
par un ou des a
8
2.4 - EXPRESSIONS REGULIERES: AUTRES POSSIBILITES
Option/Répétition de l’élément précédent
?
{n}
symbole ou groupe
élément précédent facultatif
élément précédent répété n fois
Classes de symboles : spécifient la présence d’1 symbole de la classe dans l’entrée
[xyzt]
[…a-z…]
[^…]
déf. par énumération de symboles
déf. d’intervalle
déf. par complément
Dans une classe
- les opérateurs *+? ne jouent pas
- inutile de les "échapper" par \
Délimiteurs de "contexte"
^…
…$
Ex.2.4
10/04/12
spécifie que … figure en début de ligne
spécifie que … figure en fin de ligne
[A-Za-z]+
[aeiou]
[0-9](\.[0-9]*)?
^[ \t]+$
un caractère alphabétique
une voyelle
un nombre à partie entière
une ligne "vide" (espaces ou tabulations uniquement)
9
3 ) Automates à états finis
3.1 - automates : exemples et diagrammes …………. 11
3.2 - automates à états finis : définition …………….. 13
3.3 - exemple applicatif : traitement de texte ………. 14
3.4 - mots acceptés / reconnus ……………………… 15
3.5 - conception d’une fonction de transition ………. 16
3.6 - automates déterministes / non-déterministes ….. 17
3.7 - langage reconnu par un automate ……………... 18
10/04/12
10
3.1 - AUTOMATES : EXEMPLES et DIAGRAMMES
Problème : dans l’entrée, identifier les "mots" , avec leur catégorie lexicale
PRINCIPE : utiliser des états répéter {
- lire prochain symbole e en entrée
- selon e et état courant :
. actions appropriées
. changer éventuellement l’état courant
} jusqu’à fin de reconnaissance
EXEMPLES
Ex. 3.1.1
Reconnaître 1 symbole
de programmation
ALPHA : caractères alphabétiques
ALPHANUM : alphabétiques ou numériques
e ∉ ALPHA
0
e ∈ALPHA
e ∉ ALPHANUM
NUM : chiffres décimaux
e ∈NUM
S=Se
0
e ∈ALPHANUM
1
e ∉ NUM
N = 10*N+val(e)
e ∈NUM
e ∉ NUM
2
10/04/12
Reconnaître 1 entier
et obtenir sa valeur
N = val(e)
S=e
1
Ex. 3.1.2
2
11
Ex.3.1.3
Reconnaître tous les symboles de programmation, ET tous les entiers
SEPAR {séparateurs (sauf EOF) }
EOF
marque de fin de fichier
Automate ≈ somme
des 2 précédents
NUM
{chiffres décimaux}
ALPHA
{caractères alphabétiques }
ALPHANUM {alphabétiques ou numériques }
n=s=0
e ∈SEPAR
s++
e ∈SEPAR
e ∈ALPHA
0
e ∈NUM
n++
Ss = e e=EOF Nn= val(e)
e ∈ALPHANUM
Ss= Sse
1
e = EOF
3
e = EOF
DIAGRAMMES d’AUTOMATES
e ∈SEPAR
e ∈NUM
2
Nn= 10*Nn+val(e)
Etats
Les exemples précédents utilisent des variables :
ce sont des automates à états finis
+ des ressources bornées supplémentaires
10/04/12
0 initial
n final
Transitions
(plusieurs
possibles)
condition
action
12
3.2 - AUTOMATES à ETATS FINIS : DEFINITIONS
Finite State Automata, FSA
automate A
Σ = { e1 , … eM }
symboles notant les événements présentés à A
Q = { qi, i=0, … N-1 }
ensemble fini d’états, dont :
q0 : état initial (numéroté 0, fléché)
QT ⊂ Q : états terminaux ou "accepteurs"
δ: fonction de transition
- prochain état qt+1 est fonction :
. de l’état courant qt
qt+1 = δ(qt, e )
(Σ, δ, Q, q0, QT )
. de l’événement en entrée e
- à une transition peut être associé un bloc d’actions
- par diagrammes d’états
- par tables états/transitions
SPECIFICATION d’un automate
Ex.3.2 : Tables pour l’Ex.3.1.3
0
e ∈ALPHA
Ss = e
=>1
action
prochain
état
1
Ss = Ss e
=>1
2 erreur
e ∈NUM
Nn=val(e)
e ∈SEPAR
Ss=Ss e
s ++
e = EOF
Lister
=>0 tables =>3
=>2
=>1
Nn=10Nn
=>0 +val(e) =>2
n ++
Lister
=>0 tables
Lister
tables
=>0
=>3
=>3
(3)
10/04/12
13
3.3 - Exemple d ’application : TRAITEMENT de TEXTE
PRINCIPE
- événement c en entrée = caractère lu
traducteur : génère un texte en sortie
- automate
reconnaisseur simple : accepte / rejette
c = getc()
Ex. 3.3 Supprimer les commentaires
"/* … */" du langage C
out (c)
c = getc()
c ≠ ‘/’
- Principe d’un automate (reste à traiter EOF)
0
c = ‘/’
out (‘/’, c)
c = getc() c = getc()
c ≠ ‘*’
1
c = ‘*’
- Reconnaissance par expression régulière
. une expression régulière possible :
c = getc()
c = getc()
"/*".*"*/"
. en utilisant un générateur d’analyseur lexical,
on pourra facilement lui associer l’action nulle
2
c ≠ ‘*’
c = ‘*’
c = getc()
c = getc()
c ≠ ‘/’
3
10/04/12
c = ‘/’
14
3.4 - MOTS ACCEPTES / RECONNUS par un AUTOMATE A
PRINCIPE
séquence de symboles e1, … ek
= mot accepté/reconnu par A
mène l’automate A de l’état initial q0
à un état qk ∈ QT terminal ("accepteur")
Ex. 3.4 Reconnaissance de chaîne particulière
Sur l’alphabet Σ = { a, b },
reconnaître UNE chaîne :
- contenant au moins deux b consécutifs
- éventuellement précédés d’un ou plusieurs a
- et obligatoirement suivis d’au moins un a
a) sans traitement d’erreur / de fin
a
0
b
b
1
b
2
a
3
a
b) avec traitement d’erreur / de fin d’entrée
0
a
b
1
b
EOF
EOF
2
b
a
EOF
4
ERREUR
a
3
EOF
5
FIN
- état terminal/accepteur = on a reconnu une "forme" (signification "positive" ou non) ;
ne pas arriver à un état terminal, c’est "ne pas comprendre"
- si en l’état courant qt l’entrée e n’était pas attendue, il faut traiter l’erreur.
Peut-être se repositionner pour la suite Voir => Conception d’une fonction de transition
10/04/12
15
3.5 - CONCEPTION d’une FONCTION de TRANSITION
Ex. 3.5.1
Reconnaissance de plusieurs occurrences d’une chaîne
Ex.5, sans traitement d’erreur / de fin : variante
0
a
b
1
b
2
b
a
3
a a b b a b a b b a a b b b a
a
1ère
occurrence
2ème
3ème
b
Principe simple : La reconnaissance d’une forme-type est étendue au + possible,
ou bien jusqu’au début de reconnaissance d’une autre occurrence
Remarques :
2ème
- il y a des algorithmes reconnaissant
toutes les occurrences, avec recouvrement
- on peut rechercher simultanément
plusieurs formes-type, avec ou
sans recouvrement
Ex.3.5.2 Reconnaissance de
qq. pronoms anglais
10/04/12
3ème
h
e
0
1
s
2
r
3
s
4
i
7
5
ε
h
8 e
9
ε
s
6
ε-transition :
Voir => Automates
non déterministes
16
3.6 - Automates DETERMINISTES / NON-DETERMINISTES
NFA Nondeterministic Finite state Automata
qi ek q
- pour certains (qi,ek),
j1
e
q
k
plusieurs transitions possibles q
DFA Deterministic Finite state Automata
Pour tout couple état-transition (qi,ek),
1 seule transition possible qi ek qj
i
j2
…
- et/ou il y a des ε - transitions : "sans cause"
Voir => Ex.3.5.2
- pour représenter des possibilités de choix :
la reconnaissance ne sera PAS aléatoire !! mais elle devra explorer les possibilités
- méthode : a) concevoir d’abord un NFA
b) déduire un DFA équivalent . toujours possible, avec + d’états
. algorithmes de conversion, d’optimisation
Ex.3.6
Sur l’alphabet Σ = { a, b, EOF }, - contenant au moins un a
- suivi d’exactement 2 lettres quelconques
reconnaître une chaîne :
- le tout avec un éventuel préfixe quelconque
non déterministe
a, b
0
a
a,b
1
a,b
2
3
a
b
EOF
4
0
5
a
a
Déterministe (v.simplifiée)
b
a,b
1
b
10/04/12
a,b
2
EOF
3
a
4
b
17
3.7 - LANGAGE RECONNU PAR UN AUTOMATE
Définitions
- mot M = suite de symboles ( ei1, …, eik ) pris dans un alphabet Σ = { e1, …, em }
- langage L : un ensemble donné de mots L = {Mk} ⊂ Σ*
- langage reconnu par un automate A = l’ensemble des mots acceptés / reconnus par A
Comment caractériser le langage reconnu
par un automate
spécifier
à reconnaître
a) par énumération
Souvent les langages à reconnaître sont infinis…
b) par description Ex.3.7.1
informelle
Ex.3.7.2
c) par expression régulière
10/04/12
Sur {0,1}*, mots ne contenant
pas deux ‘1’ consécutifs
a
1
b
Automate A :
a
0 b a
b
2
Automate
reconnaisseur ?
Langage
reconnu ?
Le langage reconnu par un automate à états finis
est caractérisable par expressions régulières
18
4 ) Grammaires
4.1 - exemple de grammaire, 1: spécification …………………… 20
4.2 - exemple de grammaire, 2: utilisation ………………………. 21
4.3 - notion de grammaire ambiguë ……………………………… 22
4.4 - grammaires régulières ……………………………………… 23
4.5 - grammaires d’opérateurs …………………………………… 25
5) Analyse syntaxique
5.1 - analyse syntaxique descendante : principe ………………….. 26
5.2 - analyse syntaxique descendante : exemple simple ………….. 27
5.3 - analyse syntaxique descendante : implémentation, limites …. 28
5.4 - analyse ascendante : par "shift / reduce" …………………… 29
5.5 - analyseurs et classes de grammaires ……………………….. 31
5.6 - analyseur LR(0) : principe …………………………………. 32
5.7 - definition de règles …………………………………………. 34
10/04/12
19
4.1 - EXEMPLE DE GRAMMAIRE, 1 : spécification
Ex.4.1. : esquisse d’un langage informatique simple
Program
Definitions
Règles
syntaxiques
Vocabulaire
Spécification des
catégories lexicales
(style "flex ")
10/04/12
:
:
|
;
OneTypeVarDefs :
;
VarDefList
:
|
;
VarDef
:
ScalarVarDef
:
|
;
ArrayVarDef
:
|
;
Number
:
Definitions Functions ;
OneTypeVarDefs
Definitions OneTypeVarDefs
SIMPLE_TYPE VarDefList
fin de règle
(méta-langage)
‘;’
mot du langage
VarDef
VarDefList ‘,’ VarDef
ScalarVarDef | ArrayVarDef
SYMBOL ‘=‘ Number
SYMBOL
;
SYMBOL ‘[‘ INT ‘]’
ArrayVarDef ‘[‘ INT ‘]’
INT
|
FLOAT
;
… etc …
int | char | float
[a-zA-Z] [a-zA-Z0-9]*
-?[0-9]+
return SIMPLE_TYPE ;
return SYMBOL;
return INT;
… etc …
20
4.2 - EXEMPLE DE GRAMMAIRE, 2 : utilisation
Ex.4.2
(suite Ex.4.1)
a) En production
Récursivité des règles
Program
Definitions
Functions
OneTypeVarDefs
Arbre ET/OU
de possibilités
… etc …
VarDefList
SIMPLE_TYPE
int
VarDefList
Enumération exhaustive
du langage décrit par la
grammaire : impossible
en général
‘,’
VarDef
ScalarVarDef
ScalarVarDef
SYMBOL
En limitant la profondeur
de récursion, cela reste
très calculatoire
VarDef
int
SYMBOL ‘=‘ Number
, SYMBOL = Number …
SYMBOL
encore à substituer … etc
b) En reconnaissance
- on cherche à construire UN arbre syntaxique
- ceci peut nécessiter des retours arrière (alternatives)
10/04/12
Voir => Analyse syntaxique
21
4.3 - NOTION DE GRAMMAIRE AMBIGUE
Pour au moins une chaîne d’entrée, plusieurs arbres syntaxiques possibles
Ex.4.3 : l’instruction if en langage C
Instruction : IfInstruction |
….. ‘;’ ;
IfInstruction :
if ‘(‘ Condition ‘)’ Instruction
| if ‘(‘ Condition ‘)’ Instruction else Instruction
;
Condition :
…
IfInstruction
Instruction
IfInstruction
Condition
if ( Condition1 ) if
Condition
Condition
Instruction
Condition
Instruction
Instruction
( Condition2 ) instruction1 ; else instruction2 ;
Instruction
IfInstruction
Instruction
IfInstruction
10/04/12
22
4.4 - GRAMMAIRES REGULIERES , 1
Définition
- toute partie droite de règle contient au + un symbole non-terminal
- ces symboles figurent en partie droite tous au début, ou tous à la fin
"linéaire à gauche"
" linéaire à droite"
<NTi> : <NTj>
| <NTk> <Tp1> <Tp2> …
;
Propriété
<NTi> : <NTj>
| <Tp1> <Tp2> … <NTk>
;
Le langage L(G) défini/reconnu par une grammaire régulière
peut être reconnu par une expression régulière
EX.4.4.1
VT = {a,b}
VN = { S, A}
A possibles : a ba bba …
1
S possibles : de forme S : ba bba bbba …
de forme S2 : aba abba abbba …
axiome
G
S :
|
A :
|
b A
a S
a
b A
forme S1
forme S2
L(G) peut être reconnu par l’e.r. :
10/04/12
aaba aabba aabbba …
Exemple
d’arbre syntaxique
(plusieurs possibles :
grammaire ambiguë)
a*b+ a
a
b
b
b
S1
a
A
S1
S1
S2
23
4.4 - GRAMMAIRES REGULIERES , 2
Les grammaires régulières (ou les e.r.) reconnaissent les "langages réguliers "
Ex.4.4.2
G
VN = { Symbole }
VT = { LETTRE, CHIFFRE } avec LETTRE = { A,B,…,a,b,… }
CHIFFRE = { 0,1,…, 9 }
Symbole : LETTRE
| Symbole LETTRE
| Symbole CHIFFRE
;
L(G) peut être reconnu par l’e.r. :
[A-Za-z] [A-Za-z 0-9]+
… mais sont une catégorie de grammaires aux possibilités restreintes
Ex.4.4.3
G
10/04/12
VN = { S }
VT = { 0, 1 }
- quelques mots de L(G) :
S : 0 S 1
| 0 1
;
- grammaire non régulière
01
0011
000111
…
- impossible de caractériser L(G) par exp. régulière
24
4.5 - GRAMMAIRES D’ OPERATEURS
Définition
a) aucune partie droite de règle n’est vide
b) ni ne contient 2 symboles non terminaux voisins
EX.4.5 Expressions arithmétiques en notation "infixée"
E
Expr
:
|
|
|
|
|
|
Factor :
Expr ‘+’ Expr
Expr ‘-’ Expr
Expr ‘*’ Expr
Expr ‘/’ Expr
‘-’ Expr
‘(‘ Expr ‘)’
Factor ;
SYMBOL | CONSTANT ;
E
E
E
E
F
Exemple d’expression + arbre syntaxique :
E
E
E
F
F
F
F
- ( ( b + c ) * ( d - f ) ) / e
Si on spécifiait la grammaire comme ceci
Expr : Expr Oper Expr ;
ce ne serait plus une "grammaire d’opérateurs" !
Oper : ‘+’ | ‘-’ | ‘*’ | ‘/’ ;
(bien que comportant des opérateurs arithmétiques)
10/04/12
25
5.1 - Analyse syntaxique DESCENDANTE : PRINCIPE
partir de l’axiome = symbole non terminal N1
pour reconnaître dans le texte un symbole n.t. Ni ,
il y a plusieurs queues de règle possibles Qi.1, Qi.2 , …
- on essaie tour à tour
chaque alternative Qi.j
nœud OU
-
pour reconnaître Qi.j il faut
reconnaître Qi.j1 Qi.j2 …
…
Ni : Qi.11 Qi.12 …
| Qi.21 Qi.22 …
…
nœud ET
Ni
exploration de cet arbre ET/OU de possibilités :
- en profondeur d’abord (DFS) :
on recherche UN arbre syntaxique
- avec retours-arrière si échec
Qi.1
Qi.11
10/04/12
Qi.1
Qi.2
Qi.12
Qi.2
…
26
5.2 - Analyse syntaxique DESCENDANTE : exemple simple
Ex.5.2.1
<Sentence>
<SubjVrbCplt>
<DOT>
<Sentence>
?
(cf. Ex.1.2)
?
Verizon cuts the bills .
<Sentence>
<Sentence>
<SubjVrbCplt>
<SubjVrbCplt>
<DOT>
<NounGr> <TRANS_VRB><NounGr>
<PROP_NOUN>
<ART>
?
<DOT>
?
<COMM_NOUN>
<Sentence>
<SubjVrbCplt>
<Sentence>
<DOT>
<SubjVrbCplt>
<PROP_NOUN>
<ART>
Bell
<DOT>
<PROP_NOUN>
<COMM_NOUN>
ECHEC
<ART>
Bell
<COMM_NOUN>
Verizon
SUCCES
…etc…
10/04/12
27
5.3 - ANALYSE DESCENDANTE : implémentation, limites
- choix OU : d’après le(s) prochain(s) éléments dans le texte ("look-ahead token")
. une règle est applicable si par récursion elle peut générer la prochaine unité lexicale
- implémentation possible : par appels récursifs de procédures ("descente récursive")
. pour reconnaître un symbole n.t. Ni : une procédure Rec_Ni( )
. pour chaque forme possible Qi.j de Ni, appeler Rec_Qi.j1( ) , Rec_ Qi.j2( ) …
- pas pour les grammaires "récursives à gauche"
directement :
Nom : Lettre
A : B …. ;
ou
par
récursivité
croisée
:
| Nom Lettre
B : A … ;
;
- mais on peut éliminer la récursivité à gauche par transformation de la grammaire
10/04/12
28
5.4 - Analyse ascendante : par "shift / reduce"
a) on considère une "fenêtre" de mots, étendue progressivement à droite
b) on y essaie des réductions : remplacement partie droite -> partie gauche
symbole Nj <= groupe de symboles n.t. Nik REDUCE : Appliquer une règle dans la fenêtre
c) quand aucune réduction n’est possible : SHIFT : Elargir la fenêtre à la prochaine unité
d) retour arrière en cas d’impossibilité
Verizon
Ex. 5.4.1
(reprise de Ex.1.4)
2 REDUCEs, puis SHIFT nécessaire
1 REDUCE, puis SHIFT nécessaire
1 REDUCE, puis SHIFT
cuts
the
bills
.
PROP_NOUN
NounGr
TRANS_VRB
ART
COMM_NOUN
NounGr
3 REDUCEs, puis SHIFT
SubjVrbCplt
2 REDUCEs, FIN.
10/04/12
DOT
Sentence
29
5.4 - Analyse ascendante : par "shift / reduce", suite
- on cherche toujours à réduire un suffixe de la fenêtre courante
- le contenu de la fenêtre peut être géré comme une pile
- méthode adaptée aux grammaires LALR
(Look Ahead, Left-to-right, Right reduce)
Ex.5.4.2 : grammaire d’opérateurs
Exp :
|
|
|
|
;
Exp
Exp
Exp
Exp
ID
- opérations à réaliser
- pour une grammaire
d’opérateurs, on peut
utiliser une table de
précédences d’opérateurs
10/04/12
Pile (fenêtre
de réduction)
‘+’ Exp
‘-’ Exp
‘*’ Exp
‘/’ Exp
Chaîne d’entrée
(unités lexicales)
fin
début
shift
reduce
shift
shift
reduce
reduce
shift
shift
reduce
reduce
$
$
$
$
$
$
$
$
$
$
$
ID
Exp
Exp
Exp
Exp
Exp
Exp
Exp
Exp
Exp
$ ID + ID
ID + ID
+ ID
+ ID
ID
+
+ ID
+ Exp
+
+ ID
+ Exp
+
+
+
+
+
+
+
ID
ID
ID
ID
ID
ID
ID
ID
$
$
$
$
$
$
$
$
$
$
$
$
30
5.5 - RECONNAISSANCE des LANGAGES / GRAMMAIRES
"reconnaître une grammaire G" = reconnaître le langage généré par G
difficulté dépend de la grammaire
grammaire LL
reconnaissable par Left-to-right scan, Lefttmost reduction
LR
reconnaissable par Left-to-right scan, Rightmost reduction
LR(k) idem, la reconnaissance utilisant au + k unités d’entrée en avance
reconnaissance des grammaires LR
- possible par principe d’automate :
chaque cellule de la table définissant action / prochain état
- 3 techniques possibles pour construire la table :
. canonical LR : la plus puissante / coûteuse
. LALR
: se baser sur les "look-ahead tokens "
. simple LR
: capacité de reconnaissance limitée
10/04/12
Convient bien aux
langages informatiques
31
5.6 - ANALYSEUR SYNTAXIQUE LR(0) : PRINCIPE
Décide des opérations (shift, reduce, … ) par un automate à états finis
o défini par 2 tables
o l’automate stocke dans une pile :
= la "fenêtre" précédente ; les réductions s’y feront à droite
a) les symboles
- terminaux
- non terminaux
intégrés lors d’un « shift » , encore non réduits
remplaçant les précédents lors d’un « reduce »
b) pour chaque symbole, un numéro d’état associé
Table d’actions
repris éventuellement + tard
A [ EtatCourant, SymboleT ]
o cellules non vides contiennent des opérations
sn shift : avancer d’un symbole terminal (token) x dans l’entrée
rk reduce, en appliquant la k-ième règle Rk
a accept : fin de l’analyse
sn
- empiler le token x,
avec pour n° d’ état associé n
- se placer dans l’état n
X : A1 … ANk
symbole n.t. qui sera obtenu par réduction
rk
o cellules vides = cas d’erreur
- dépiler Nk symboles =>
nouveau sommet de pile, état associé em
Table de changements d’états
o les cellules non vides définissent
des changements d’état
10/04/12
gn « go to n »
G[ EtatRepris, SymboleNT ]
- prochain état e’ = G [em , X ]
- empiler le symbole réduit X + n° d’état associé e’
- passer en l’état
e’
32
5.6 – ANALYSEUR SYNTAXIQUE LR(0) : EXEMPLE
A : Actions
(
Grammaire
0
1
2
3
4
Texte
Tables
S’ :
S :
S :
L :
L :
S $
( L )
x
S
L , S
( x ) $
. ( x
Analyse
1
2
3
4
5
6
7
8
9
s3
r2
s3
)
x
r2
s2
r2
s2
,
$
G : Chgts d’état
S
L
g4
r2
r2
g7
g5
a
r1
r3
s3
r4
s6
r1
r3
r4
s8
r1 r1 r1
r3 r3 r3
s2
r4 r4 r4
g9
) $
1
s3 par A [1, ( ] - Empiler (/3 - Nouvel état = 3
( . x ) $
1
3
(
1
s2 par A [ 3,x ] - Empiler x/2 - Nouvel état = 2
x . ) $
3
2
reduce par R2, X=S ; Top=3 : par G [ 3,S], empiler S/7 - Nouvel état = 7
( S . ) $
1
3 7
reduce par R3, X=L ; Top=3 : par G [ 3,L], empiler L/5 - Nouvel état = 5
( L .)
1
$
3 5
s6 par A [ 5, ) ] - Empiler )/6 - Nouvel état = 6
( L ) .$
10/04/12
1
3 5
1
S4
6
reduce par R1, X=S ; Top = 1 : par G [ 1,S], empiler S/4
.$
a par A [ 4,$ ]
33
5.7 - DEFINITION DE REGLES, 1: souvent plusieurs solutions
EX. Reconnaître des définitions
de tableaux d’entiers, en C
On veut pouvoir reconnaître :
int X3[ ] = { 0, 1, 2 }
int a[ ] = { };
int b2c[3 ];
int zz[ ];
Une solution, à discuter
1)
2)
3)
4)
5)
6)
7)
8)
10/04/12
…
IntArrayDef
: IntArrayDefWithoutDim ‘=‘ IntArrayInit ‘;’
| IntArrayDefWithDim ‘;’
| IntArrayDefWithoutDim ‘;’
;
IntArrayDefWithDim
: INT_TYPE ID ‘[‘ INT_VAL ‘]’
;
IntArrayDefWithoutDim : INT_TYPE ID ‘[‘ ‘]’
;
IntArrayInit
: ‘{‘ IntValList ‘}’
| ‘{‘ ‘}’
;
IntValList
: INT_VAL
| IntValList ‘,’ INT_VAL
;
…
Spécifier l’analyseur lexical
IntValList : Pourquoi imposer au moins une INT_VAL ?
IntArrayInit : Role de la 2eme alternative ?
IntArrayDef : chaque alternative spécifie un ‘;’ final : est-ce judicieux
Ajouter une 1ère règle pour traiter une suite de IntArrayDef
Ajouter une récupération d’erreur
La catégorie lexicale INT_VAL figure à 2 endroits ; cela va-t-il créer une ambiguïté, si oui laquelle ?
Dans la solution ci-dessus, la notion IntValList est reconnue au niveau syntaxique
a – Si on veut passer des valeurs du niveau lexical au niveau syntaxique
- quel devrait être le type (défini par %type) donné au symbole n.t. IntValList ?
- au niveau syntaxique, comment pourrait-on stocker les valeurs successives ?
b – Alternative : si on voulait reconnaître la même notion par l’analyseur lexical (retournant
la catégorie INT_VAL_LIST), quels seraient les avantages, inconvénients, difficultés ?
34
5.7 - DEFINITION DE REGLES, 2:
si possible, éviter les conflits ; surtout les conflits reduce / reduce !
EX. Approche progressive
Version 0 d’analyseur syntaxique :
Se contente d’obtenir les u.lexicales une à une
Text :
| Text LexUnit
{ fprintf(stderr, " <LexUnit> " ); }
;
LexUnit : P_NOUN
| C_NOUN
| ART
| TRANS_VERB
| ‘,’
| ‘.’
;
Version 1 de l’analyseur : on commence à introduire
des règles significatives, en identifiant une 1e notion utile
Text :
| Text NounGroup
{ fprintf(stderr, " <NounGroup> " ); }
| Text LexUnit
{ fprintf(stderr, " <LexUnit> " ); }
;
NounGroup : P_NOUN
| ART C_NOUN
;
LexUnit : P_NOUN
| C_NOUN
| ART
| TRANS_VERB
| ‘,’
| ‘.’
;
⇒Conflits ( reduce / reduce, shift / reduce)
- pourquoi ?
- comment modifier la grammaire ?
10/04/12
35

arbre syntaxique decrit la structure d`une forme.

Transcription

Documents pareils

enquête - Telecom SudParis

Sécurité des systèmes et des réseaux

Voir le communiqué de presse

CV FRANCAIS Nicolas Cudon

un cursus ingénieur bi-diplômant entre tunis et paris : la filière tunis

Décharge de responsabilité

Jouets et jeux de plein air : quelques précautions d`usage

LYCEE JEAN PERRIN 2, avenue Vauban 59130 LAMBERSART

Orange, parrain de la promotion 2015

Séminaire