les erreurs de syntaxe - Gallium

Transcription

les erreurs de syntaxe - Gallium
Un compilateur OCaml qui explique (toutes!)
les erreurs de syntaxe
Proposition de stage de recherche (niveau M1)
19 novembre 2015
Encadrant
François Pottier, directeur de recherche, INRIA Paris ([email protected])
Résumé
L’objectif de ce stage est d’utiliser certains outils récemment ajoutés au générateur d’analyseurs
syntaxiques Menhir pour améliorer considérablement la qualité des messages d’erreur de syntaxe
produits par le compilateur OCaml.
Sujet
D’après certaines croyances populaires, les analyseurs syntaxiques LR(1) engendrés à partir d’une
grammaire sont incapables de produire une explication de bonne qualité lorsqu’ils rencontrent une
erreur de syntaxe. D’après ce folklore, pour obtenir des messages d’erreur de bonne qualité, il faudrait
écrire l’analyseur syntaxique à la main, de préférence en utilisant une technique descendante, comme
LL(1).
C’est dommage, d’une part parce que la technique LL est moins puissante que la technique LR,
d’autre part parce qu’il est beaucoup plus facile de maintenir et de faire évoluer une grammaire
plutôt qu’un analyseur syntaxique. Écrire une grammaire, plutôt qu’un analyseur, permet d’adopter
un style déclaratif, plutôt qu’impératif.
Pour tenter de remédier à cette situation et pour contredire ces croyances, j’ai récemment doté
Menhir, un générateur d’analyseurs LR(1), d’outils qui permettent de comprendre (et de contrôler)
dans quels états de l’automate LR(1) une erreur peut se produire. On peut alors, comme le propose
Jeffery [1], doter l’automate d’un message d’erreur adapté à chacun de ces états. J’ai appliqué cette
approche avec succès à l’analyseur syntaxique de CompCert, un compilateur pour le langage C99.
Ces résultats sont relatés dans un article soumis pour publication [2].
L’objectif de ce stage est d’appliquer ces outils à l’analyseur syntaxique du compilateur OCaml, de
façon à améliorer considérablement la qualité de ses messages d’erreur de syntaxe, qui actuellement
laisse à désirer. (Aujourd’hui, cet analyseur est engendré par l’outil ocamlyacc. Des travaux sont en
cours pour le transférer vers Menhir ; cela devrait être fait avant le début du stage.)
Cet objectif est assez ambitieux, car la grammaire du langage OCaml est relativement complexe :
elle est trois fois plus grosse que celle de CompCert, et fait apparaître des conflits plus nombreux.
Il faut parfois modifier la grammaire de façon à faciliter l’explication des erreurs. Chacune de ces
modifications devra s’accompagner de tests sérieux, afin de vérifier qu’aucun « bug » n’est introduit.
La technique de Jeffery prévoit l’écriture manuelle d’un message d’erreur pour chaque état de
l’automate où une erreur peut se produire. Toutefois, si cette technique se révèle trop limitée ou
trop coûteuse en termes d’effort humain, on pourra imaginer d’autres techniques, où le message
d’erreur serait construit soit de façon entièrement automatique, soit de façon semi-automatique par
1
assemblage de fragments de messages préparés par un humain. Menhir offre une boîte à outils à
l’aide de laquelle on peut faire preuve d’inventivité.
Enfin, cette technique repose sur un algorithme d’accessibilité que j’ai implémenté dans Menhir.
Cet algorithme est coûteux : il exige environ 2.5 minutes pour analyser la grammaire d’OCaml. Si le
temps le permet et si on le souhaite, on pourra chercher à optimiser cet algorithme, voire imaginer
un algorithme entièrement différent.
Pré-requis
Des bases solides en programmation en général et en OCaml en particulier sont indispensables.
Une certaine connaissance de la théorie des langages formels et de l’analyse syntaxique n’est pas
absolument indispensable, mais serait bienvenue.
Détails pratiques
Le stage se déroulera à l’INRIA, sur le site de Paris (proche de la Gare de Lyon), sous la direction
de François Pottier, d’avril à juillet 2016 environ.
Si cette proposition de stage vous intéresse, n’hésitez pas à me contacter pour en savoir plus.
Références
[1] Clinton L. Jeffery. Generating LR syntax error messages from examples. ACM Transactions on
Programming Languages and Systems, 25(5) :631–640, 2003.
[2] François Pottier. Reachability and error diagnosis in LR(1) automata. Submitted for publication,
2015.
2