summaryrefslogtreecommitdiffstats
path: root/notes-inf105.tex
diff options
context:
space:
mode:
Diffstat (limited to 'notes-inf105.tex')
-rw-r--r--notes-inf105.tex142
1 files changed, 97 insertions, 45 deletions
diff --git a/notes-inf105.tex b/notes-inf105.tex
index 470a46c..818b58b 100644
--- a/notes-inf105.tex
+++ b/notes-inf105.tex
@@ -4820,8 +4820,8 @@ langage $L(G)$ que la précédente (elle est donc faiblement équivalente
inambiguë (cf. \ref{ambiguous-grammar}), il ne peut pas être analysé
par un analyseur LL (cf. \ref{handwaving-on-ll-and-lr}).)\par}
-\thingy Sur l'alphabet $\Sigma = \{a,b\}$, considérons la grammaire
-(d'axiome $S$)
+\thingy\label{example-unambiguous-but-not-deterministic-grammar} Sur
+l'alphabet $\Sigma = \{a,b\}$, considérons la grammaire (d'axiome $S$)
\[
\begin{aligned}
S &\rightarrow U \;|\; V \;|\; \varepsilon\\
@@ -4830,11 +4830,12 @@ V &\rightarrow aVbb \;|\; abb\\
\end{aligned}
\]
Il est clair que le langage $L(G,U)$ des mots qui dérivent de $U$ est
-$\{a^i b^i : i>0\}$ comme en \ref{basic-example-context-free-grammar},
-et de façon analogue, le langage $L(G,V)$ des mots qui dérivent de $V$
-est $\{a^i b^{2i} : i>0\}$. Le langage $L(G) = L(G,U) \cup L(G,V)$
-est donc l'ensemble des mots de la forme $a^i b^j$ où $j=i$ \emph{ou
- bien} $j=2i$.
+$\{a^i b^i : i\geq 1\}$ comme
+en \ref{basic-example-context-free-grammar}, et de façon analogue, le
+langage $L(G,V)$ des mots qui dérivent de $V$ est $\{a^i b^{2i} :
+i\geq 1\}$. Le langage $L(G) = L(G,U) \cup L(G,V)$ est donc
+l'ensemble des mots de la forme $a^i b^j$ où $i\geq 1$ et $j=i$
+\emph{ou bien} $j=2i$.
{\footnotesize (Ce langage est intéressant sur le plan théorique, car
bien qu'il soit algébrique et défini par une grammaire inambiguë
@@ -5461,6 +5462,8 @@ les automates à pile déterministes (qu'il faut définir soigneusement)
acceptent strictement moins de langages que les automates à pile
non déterministes.
+\bigbreak
+
\thingy Une approche simple, quoique terriblement inefficace, pour
résoudre algorithmiquement, \emph{en théorie}, le problème de décider
si un mot $w$ appartient au langage $L(G)$ engendré par une grammaire
@@ -5649,49 +5652,93 @@ cubique en la longueur de $w$.
\par}
-\thingy\label{handwaving-on-ll-and-lr} Du point de vue pratique, il existe deux approches principales
-pour analyser les langages définis par des grammaires hors contexte
-(supposées \emph{au minimum} inambiguës) :
+\bigbreak
+
+\thingy\label{handwaving-on-ll-and-lr} Du point de vue pratique, on ne
+cherche pas simplement à savoir si un mot appartient au langage
+engendré par une grammaire, mais aussi à en construire un arbre
+d'analyse ; par ailleurs, la complexité algorithmique des approches
+décrites en \ref{algebraic-languages-are-decidable} et meme
+en \ref{handwaving-on-dynamical-programming} est inacceptable. En
+contrepartie de ces exigences, on est prêt à accepter de mettre des
+contraintes sur la grammaire qui la rendent plus facile à analyser :
+\emph{au minimum}, on supposera que la grammaire est inambiguë
+(cf. \ref{ambiguous-grammar}), et en fait, on imposera des contraintes
+beaucoup plus fortes (par exemple, la grammaire présentée
+en \ref{example-unambiguous-but-not-deterministic-grammar}, bien
+qu'inambiguë, ne sera pas acceptable car il n'y a pas de manière
+déterministe de l'analyser, ni même d'analyser le langage qu'elle
+engendre) ; ces contraintes sont assez techniques et difficiles à
+décrire : dans la pratique, elles consistent essentiellement à essayer
+de fabriquer l'analyseur et à constater si l'algorithme échoue.
+
+Il existe deux principales approches pour construire un analyseur pour
+une grammaire hors contexte (sujette à diverses contraintes
+supplémentaires) ; dans les deux cas, on construit une sorte
+d'automate à pile (cf. \ref{handwaving-on-stack-automata})
+déterministe, mais l'utilisation de la pile est très différente dans
+les deux cas. De façon très simplifiée :
\begin{itemize}
-\item Les analyseurs \defin[LL (analyse)]{LL} procèdent de façon \emph{descendante} (en
- anglais « top-down »), parcourent le mot depuis la gauche (« L ») et
- génèrent la dérivation gauche (« L ») de l'arbre d'analyse fabriqué,
- en partant de la racine et en descendant jusqu'aux
- feuilles\footnote{En botanique, un arbre a la racine en bas et les
- feuilles en haut ; en informatique, on les représente plutôt
- racine en haut et feuilles en bas.}.
-\item Les analyseurs \defin[LR (analyse)]{LR} procèdent de façon \emph{ascendante} (en
- anglais « bottom-up »), parcourent le mot depuis la gauche (« L »)
- et génèrent la dérivation droite (« R ») de l'arbre d'analyse
- fabriqué, en partant des feuilles et en remontant jusqu'aux racines.
+\item Les analyseurs \defin[LL (analyse)]{LL} procèdent de façon
+ \emph{descendante} (en anglais « top-down »), parcourent le mot
+ depuis la gauche (« L ») et génèrent la dérivation gauche (« L ») de
+ l'arbre d'analyse fabriqué, en partant de la racine et en descendant
+ jusqu'aux feuilles\footnote{En botanique, un arbre a la racine en
+ bas et les feuilles en haut ; en informatique, on les représente
+ plutôt racine en haut et feuilles en bas.}. La pile de
+ l'analyseur LL sert, intuitivement, à mémoriser les règles qu'on a
+ commencé à reconnaître, en partant de l'axiome de la grammaire, et
+ qui restent encore à compléter.
+\item Les analyseurs \defin[LR (analyse)]{LR} procèdent de façon
+ \emph{ascendante} (en anglais « bottom-up »), parcourent le mot
+ depuis la gauche (« L ») et génèrent la dérivation droite (« R ») de
+ l'arbre d'analyse fabriqué, en partant des feuilles et en remontant
+ jusqu'aux racines. La pile de l'analyseur LR sert, intuitivement, à
+ mémoriser les fragments d'arbre déjà construit, en partant des
+ feuilles, et qui restent encore à regrouper.
\end{itemize}
+On peut écrire un analyseur LL ou (plus difficilement) LR à la main
+dans un cas simple, mais en général ces analyseurs sont fabriqués par
+des algorithmes systématiques, implémentés dans des programmes tels
+que YACC ou Bison (qui produit des analyseurs LR, même si Bison peut
+dépasser ce cadre) ou JavaCC (qui produit des analyseurs LL).
+
L'idée générale à retenir est que les analyseurs LR sont strictement
plus puissants que les analyseurs LL (ils sont capables d'analyser
strictement plus de grammaires, cf. \ref{example-lr-non-ll-grammar}),
-mais leur écriture est plus difficile et les messages d'erreur qu'ils
-retournent sont plus difficiles à comprendre.
+mais leur génération est plus difficile et les messages d'erreur
+qu'ils retournent en cas de problème de syntaxe sont plus difficiles à
+comprendre pour l'utilisateur.
-\thingy Pour illustrer ces différences, considérons une grammaire très
-simple à analyser comme
+\thingy\label{example-ll-and-lr-analysis} Pour illustrer le
+fonctionnement et les différences des analyseurs LL et LR, considérons
+une grammaire très simple à analyser comme
\[
\begin{aligned}
S &\rightarrow TS \;|\; c\\
T &\rightarrow aSb\\
\end{aligned}
\]
+(il s'agit d'une variante de celle considérée
+en \ref{example-well-parenthesized-expressions}, où on a ajouté un $c$
+pour rendre l'analyse plus simple en évitant les
+productions $\varepsilon$ ; on peut imaginer, si on veut, qu'il s'agit
+d'une forme extrêmement primitive de XML où $a$ représente une balise
+ouvrante, $b$ une balise fermante, et $c$ une balise vide).
L'approche la plus évidente, si on doit écrire une fonction « analyser
-un mot comme dérivant de $S$ dans cette grammaire » consiste à faire
+un mot comme dérivant de $S$ dans cette grammaire » consiste à coder
deux fonctions mutuellement récursives, « chercher un préfixe qui
dérive de $S$ » et « chercher un préfixe qui dérive de $T$ ». En
observant que tout mot qui dérive de $T$ doit commencer par la
lettre $a$, ce qui permet de distinguer les mots dérivant des règles
$S\rightarrow TS$ et $S\rightarrow c$, on va écrire :
\begin{itemize}
-\item Fonction « rechercher un préfixe qui dérive de $S$ » (prenant en
- entrée un mot $w\in\{a,b\}^*$, et renvoyant un préfixe de $w$ et un
- arbre de dérivation de $w$ à partir de $S$) :
+\item La fonction « rechercher un préfixe qui dérive de $S$ » (prenant
+ en entrée un mot $w\in\{a,b\}^*$, et renvoyant un préfixe de $w$ et
+ un arbre de dérivation de $w$ à partir de $S$) est définie comme
+ suit :
\begin{itemize}
\item si la première lettre de $w$ est $c$, renvoyer le préfixe $c$ et
l'arbre trivial $S\to c$, sinon :
@@ -5709,9 +5756,10 @@ $S\rightarrow TS$ et $S\rightarrow c$, on va écrire :
racines de sous-arbres donnés par $\mathscr{U}$ et $\mathscr{V}$
respectivement).
\end{itemize}
-\item Fonction « rechercher un préfixe qui dérive de $T$ » (prenant en
- entrée un mot $u\in\{a,b\}^*$, et renvoyant un préfixe de $u$ et un
- arbre de dérivation de $u$ à partir de $T$) :
+\item La fonction « rechercher un préfixe qui dérive de $T$ » (prenant
+ en entrée un mot $u\in\{a,b\}^*$, et renvoyant un préfixe de $u$ et
+ un arbre de dérivation de $u$ à partir de $T$) est définie comme
+ suit :
\begin{itemize}
\item vérifier que la première lettre est un $a$ (sinon, soulever une
exception indiquant une erreur d'analyse),
@@ -5733,18 +5781,22 @@ $S\rightarrow TS$ et $S\rightarrow c$, on va écrire :
Cette approche réussit sur cette grammaire très simple (où on peut
notamment se convaincre que l'éventuel préfixe dérivant de $S$ ou de
$T$ est toujours défini de façon unique). L'analyseur qu'on vient de
-décrire s'appelle un « analyseur par descente récursive » ; mais
-plutôt qu'utiliser la récursivité du langage de programmation
-(c'est-à-dire la pile système), on peut aussi utiliser une pile comme
-structure de données, et on obtient ainsi essentiellement un automate
-à pile, qui utilise sa pile pour retenir les règles qu'il a commencé à
-analyser (à partir de la racine de l'arbre d'analyse en cours de
-construction). On a essentiellement construit un analyseur LL, ou
-plus exactement LL($1$) (le « $1$ » indiquant qu'on se contente de
-lire une unique lettre du mot pour décider quelle règle chercher à
-analyser), pour ce langage. C'est ici l'approche « descendante » :
-l'arbre se construit à partir de la racine et la pile sert à retenir
-les règles qu'on a commencé à reconnaître.
+décrire s'appelle un « analyseur par descente récursive ». Or, plutôt
+qu'utiliser la récursivité du langage de programmation (c'est-à-dire
+la pile système), on peut aussi utiliser une pile comme structure de
+données, et transformer les fonctions récursives en fonctions
+itératives\footnote{Ceci est un fait général : tout ensemble de
+ fonctions récursives peut se réécrire pour utiliser une pile comme
+ structure de données explicite à la place de la pile système.}. On
+obtient ainsi essentiellement un automate à pile, qui utilise sa pile
+pour retenir les règles qu'il a commencé à analyser (à partir de la
+racine de l'arbre d'analyse en cours de construction). On a
+essentiellement construit un analyseur LL, ou plus exactement LL($1$)
+(le « $1$ » indiquant qu'on se contente de lire une unique lettre du
+mot pour décider quelle règle chercher à analyser), pour ce langage.
+C'est ici l'approche « descendante » : l'arbre se construit à partir
+de la racine et la pile sert à retenir les règles qu'on a commencé à
+reconnaître.
\smallbreak
@@ -5774,7 +5826,7 @@ tel analyseur, mais sur cet exemple précis il est facile de se
convaincre qu'il fonctionne et de comprendre pourquoi : il s'agit
essentiellement là d'un analyseur LR (en fait, LR($0$), le « $0$ »
indiquant qu'on n'a jamais eu besoin de regarder au-delà du symbole
-courant pour décider quoi faire), C'est ici l'approche
+courant pour décider quoi faire). C'est ici l'approche
« ascendante » : l'arbre se construit à partir des feuilles et la pile
sert à retenir les nonterminaux au sommet des morceaux d'arbre déjà
construits (et éventuellement les arbres eux-mêmes).