search

shangoue / ell

libELL: library to simply Embed LL grammar & parser inside C++ code
GNU Lesser General Public License v3.0
1 stars 1 forks source link

Give a simpler list of possible tokens in error messages #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Les messages d'erreur émis par l'opérateur d'aggrégation en mode
no-step-back fonctionnent très bien.

Par contre, on tombe dans le travers des parseurs LL quand il reste des
tokens non consommés en fin de flux.

Par exemple:

root = dec % ch(',') >> (eos | error("unexepected token"));

Si l'on parse une chaîne dans laquelle l'utilisateur a oublié une virgule
"1, 2 3", on obtient le message:

1: before "3": unexpected token

Bon, deux façons de répondre au problème :
 a) "c'est la life", on ne change rien
 b) Changer le message pour : 1: before "3": expecting ',' or <EOS>

La solution b) fait très pro, c'est digne d'un parseur LR, et c'est tout à
fait possible de l'implémenter, même si cela induit un léger overhead.

L'idée est simplement de maintenir dans la classe Parser une listes des
règles que l'on a pas réussi à matcher sur un token particulier. Dès qu'on
consomme un token, cette liste est remise à zéro.

Ce mécanisme ne doit être actif que si l'on se trouve en mode no-step-back,
sans quoi on a pas le droit de vider la liste à chaque consommation et ça
devient vite horrible.

Original issue reported on code.google.com by samuel.h...@gmail.com on 8 Apr 2009 at 8:07

GoogleCodeExporter commented 9 years ago 
A noter que les seules noeuds dont il est intéressant de se rappeler l'échec 
de
matching sont les primitives, sinon les messages d'erreur deviendront 
complètement
illisibles.

Il faut également ne pas tenir compte des primitives utilisées dans le 
skipper.
Pour ce faire, on pourrait rendre la fonction parse template du skipper. Ce qui 
fait
que :
  * il n'y aurait plus de test sur la valeur du skipper
  * il n'y aurait plus d'appels à skip() lorsque ce n'est pas nécessaire

Ce n'est cependant pas évident d'avoir une implémentation propre sans tomber 
dans la
lourdeur.

Original comment by samuel.h...@gmail.com on 8 Apr 2009 at 1:22

GoogleCodeExporter commented 9 years ago

Original comment by samuel.h...@gmail.com on 17 Apr 2009 at 9:30

GoogleCodeExporter commented 9 years ago

Original comment by samuel.h...@gmail.com on 17 Apr 2009 at 9:39

GoogleCodeExporter commented 9 years ago

Original comment by samuel.h...@gmail.com on 17 Apr 2009 at 2:23

GoogleCodeExporter commented 9 years ago

Original comment by samuel.h...@gmail.com on 17 Apr 2009 at 2:25

GoogleCodeExporter commented 9 years ago 
Il ne faut pas oublier de prendre en compte l'opérateur || : il faut dans ce 
cas
afficher les tokens possibles au point le plus loin atteint au niveau 
syntaxique (pas
au niveau lexical).

Original comment by samuel.h...@gmail.com on 3 Aug 2009 at 12:02

GoogleCodeExporter commented 9 years ago

Original comment by samuel.h...@gmail.com on 28 Jan 2011 at 2:07