Nous avons dit plus haut que lesDCGconstituent un outil de programmation simple d’emploi, puissant, et flexible. Elles pr´esentent cependant une difficult´e qui vient de ce que la strat´egie de l’analyseur r´esultant de la traduction deDCGen Prolog est en g´en´eral directement h´erit´ee de celle du syst`eme Prolog sous-jacent. Or, la strat´egie la plus souvent employ´ee en Prolog correspond au niveau syntaxique `a une analyse par descente r´ecursive et est donc incompl`ete.
Une mani`ere de compenser ce biais strat´egique est de changer la strat´egie de Prolog en choisissant par exemple une strat´egie tabul´ee [Warren 92], et une autre est de changer la proc´edure de traduction deDCGen Prolog. Nous avons choisi une troisi`eme voie qui est de transformer les grammaires pour qu’elles soient compatibles avec une analyse par descente r´ecursive.
Le principal obstacle `a lever est celui de la r´ecursivit´e `a gauche, mais il faut aussi pouvoir effectuer des d´epliages, ou des factorisations. Ces transformations sont bien for- malis´ees pour les grammaires pures, mais pas du tout pour les grammaires `a attributs (dont lesDCGsont un cas particulier). Conduire ces transformations `a la main est une tˆache r´epu- t´ee difficile. Au sujet de la transformation manuelle desDCG, Cohen et Hickey parlent de
((cunning))(ruse ou astuce) et((contortions))[Cohen et Hickey 87]. Nous avons donc voulu
formaliser et automatiser ces transformations.
La transformation desDCGn’est qu’un aspect de nos motivations. En fait, mˆeme quand le moteur d’analyse est plus complet que la descente r´ecursive, on peut encore avoir besoin
de transformer les grammaires pour am´eliorer les performances.
La difficult´e de la transformation des grammaires `a attribut vient ´evidemment des at- tributs. Quand une transformation introduit de nouveaux non-terminaux, quels sont leurs attributs ? Quand une transformation combine plusieurs r`egles de grammaire, comment se combinent les attributs?
Nous avons mod´elis´e les grammaires `a attributs dans un formalisme qui s´epare la partie syntaxique pure de la partie s´emantique [Ridoux 96]. Nous notons Syntaxe
./
Semantiquel’adjonction d’un composant s´emantique Semantique `a un composant syntaxique pur Syn-
taxe. Le composant s´emantique est exprim´e comme une fonction des attributs des ´el´ements
syntaxiques purs qui retourne une formule logique ; c’est donc un pr´edicat. Par exemple, dans la r`egle
!
./
R, le composant s´emantiqueRest une fonction des attributs du non-terminal de tˆete et des deux non-terminaux du corps. En admettant la-´equivalence(87),on aurait pu ´ecrire
!
./
12
(R
1
2
). On convient que les ´el´ements syn-
taxiques purs sont toujours consid´er´es de gauche `a droite dans les arguments des compo- sants s´emantiques.
On peut rapprocher cette mod´elisation de la mod´elisation de la programmation par
induction structurelle(112)en Prolog typ´e. Ici, le type est celui des arbres de d´erivation et les
constructeurs sont les r`egles de grammaires.
Les combinaisons d’attributs s’expriment donc par application de fonction et construc- tion de formules logiques. Par exemple, le principe de l’´elimination des r´ecursivit´es gauches imm´ediates est exprim´e de la mani`ere suivante :
!
./
R(pour chaque
)
!
./
S(pour chaque
) #
!
0
./
0 9u
[Su
^0 =(
u;
)] (pour chaque)
0 !
0
./
0 10 29
u
[Ru
0 1:
gauche^
0 2=(
u;
0 1:
droite)] (pour chaque)
0 !
./
0 (0
:
gauche=0
:
droite)La transformation de la partie syntaxique pure est classique [Aho et al. 86] et toute la nouveaut´e r´eside dans la prise en compte des attributs. En admettant que le non-terminal
est d´efini par des r`egles r´ecursives `a gauche, ayant pour composants s´emantiques desR
,
et des r`egles qui ne le sont pas, ayant pour composants s´emantiques desR
, on peut le
red´efinir par des r`egles dont aucune n’est r´ecursive `a gauche, et dont les composants s´e- mantiques sont construits `a partir desR
etR
. En particulier, un non-terminal nouveau,
0
, est introduit. Son attribut est une paire dont les composants sont d´esign´es par notation point´ee, .gauche et .droite.
La combinaison de cette transformation et d’une transformation par d´epliage permet d’´eliminer les r´ecursivit´es indirectes. Des manipulations symboliques, comprenant un peu d’´evaluation partielle, permettent de formuler les nouvelles r`egles de grammaire dans leur syntaxe concr`ete.
Le syst`eme qui met en œuvre cette formalisation transforme automatiquement les r`egles de grammaire suivantes, qui d´ecrivent un nombre et sa valeur chiffre par chiffre en com-
men¸cant par la droite14,
nombre Nombre ––
>
nombre Dizaines&chiffre Unites&
‘ ( Nombre is Unites + 10*Dizaines /* Horner */ ) . nombre Chiffre ––
>
chiffre Chiffre .en les r`egles suivantes, qui commencent par la gauche :
nombre 135 ––
>
chiffre Chiffre&derec nombre 135 Chiffre .derec nombre 127 Dizaines ––
>
chiffre Unites&‘ ( Nombre is Unites + 10*Dizaines /* Horner */ )&
derec nombre 127 Nombre . derec nombre 141 141 ––
>
[] .Si on se souvient de la relation entreDCGet Prolog, on doit convenir qu’il s’agit en fait d’une transformation de programmes produits d’apr`es un sch´ema particulier. En l’occur- rence, la transformation d´ecrite plus haut ´elimine r´eellement les r´ecursivit´es `a gauche d’un programme Prolog.
Le syst`eme que nous avons impl´ement´e conserve autant que possible les identifica- teurs de variables et les commentaires des r`egles sources dans les r`egles produites. Cela permet d’augmenter la lisibilit´e des grammaires produites. C’est un aspect mal trait´e par la recherche sur les transformations de programme et qui constitue un mode rudimentaire d’explication de ce que fait le syst`eme. Il faut aussi noter que cela a un prix, en temps de programmation du syst`eme et en temps de calcul des transformations. Dans le cas de ce syst`eme, la tra¸cabilit´e est la cause du doublement de la taille du programme.
On voit que le formalisme propos´e est parent de
Prolog par le fait qu’il combine -abstractions(67)et quantifications logiques. On peut donc suspecter que notre biais pour Prolog a guid´e notre formalisation. Nous croyons qu’il faut consid´erer les choses d’une autre mani`ere.Prolog met en œuvre une formalisation de la m´etalangue employ´ee pour manipuler les structures formelles. Il n’est donc pas ´etonnant que l’usage de la m´etalangue d´ej`a formalis´ee m`ene plus directement au but. On peut mˆeme penser que cela se reproduira. Plus g´en´eralement, une autre raison pour laquelle un langage de programmation ne doit pas ˆetre consid´er´e comme neutre (voir la section((La recherche en programmation))— page 8)est qu’il offre une((vision du monde)). Celle-ci encourage un style de formalisation des
probl`emes `a r´esoudre.
Applications
Les applications pr´ef´erentielles de
Prolog sont d’abord celles qui ont motiv´e l’ajout des -termes : manipulation de formules, calcul de d´enotation, etc. Parmi les applica- tions effectivement ´etudi´ees, on trouve la d´emonstration automatique [Belleann´ee 91, Felty 93], l’analyse des langues naturelles [Miller et Nadathur 86a, Pareschi et Miller 90, Dalrymple et al. 91, Coupet-Grimal et Ridoux 95], la manipulation des langages formels14. La syntaxe est la mˆeme plus celle d´ecrite plus haut, avec en plus un point de g´en´eration introduit par le signe((‘)).
et de leurs grammaires [Le Huitouze et al. 93a, Co¨uasnon et al. 95, Ridoux 96] (voirgram- maires logiques(90)et section
((
Prolog et grammaires formelles))— page 44), et la mani-pulation de programmes fonctionnels [Hannan et Miller 92]. Mentionnons aussi le fait que la structure de
Prolog rend compte sans ajout extra-logique de constructions comme lesmodules(105)[Miller 93] et lestypes abstraits(135)[Miller 89a].
Dans la suite, nous d´ecrivons un peu plus pr´ecis´ement deux types d’applications de
Prolog qui ont ´et´e d´evelopp´ees avec le syst`eme Prolog/MALI. D’un troisi`eme type nous ne donnons que les caract´eristiques de tailles car ces applications sont d´ecrites ailleurs (voir sections((Un syst`eme ouvert))— page 42 — et((Transformations de grammaires en Prolog))— page 47).