Commit 4d5604cf authored by POTTIER Francois's avatar POTTIER Francois
Browse files

TODO update.

parent 73107c3f
* Ongoing work on positions.
Remove the function [positions] in the incremental API? or update its doc.
- on peut offrir un $symbolstartpos(i) qui calcule de la même
manière que Parsing.symbol_start_pos.
* Develop an alternate src/Makefile that does not require ocamlbuild?
Could use OCamlMakefile instead, for instance.
......@@ -45,6 +47,7 @@
bison. Réfléchir... et corriger les deux back-ends. Attention
toutefois, c'est un changement incompatible. Option de ligne
de commande?
(voir aussi messages de Tiphaine Turpin à partir du 30/08/2011)
Idée de F. Bour: on pourrait annoter une production %default
pour indiquer qu'elle doit toujours être réduite par défaut.
Réfléchir à l'impact sur les positions.
......@@ -55,13 +58,6 @@
à savoir éliminer toutes les autres actions. Que fait
ocamlyacc?
* Améliorer la compatibilité avec ocamlyacc sur les positions.
Deux aspects indépendants:
- le calcul de $endpos pour une production epsilon doit se
faire en consultant la pile, et non pas le prochain token;
- on peut offrir un $symbolstartpos(i) qui calcule de la même
manière que Parsing.symbol_start_pos.
* autoriser %token FOO "foo"
pour pouvoir afficher les tokens sous forme plus lisible
et auto-générer une fonction (ou une table) print_terminal
......@@ -107,32 +103,10 @@
incompatible in principle with --explain. Modify the code to fail
gracefully when the problem arises.
* les positions fournies par menhir ne sont pas les mêmes fournies par
ocamlyacc (voir messages de Tiphaine Turpin à partir du 30/08/2011).
Est-ce un problème? Peut-on documenter quelles sont les
positions fournies par Menhir? En particulier, pour une production
vide, Menhir utilise _menhir_env.lexer.lex_start_p, c'est-à-dire le
début du dernier token lu par le lexer; en principe c'est le token
de lookahead donc ça va, mais ça pourrait donner un résultat bizarre
si on réduit par défaut une production vide (on a alors pour position
le début du token précédent?) (BUG?). Par ailleurs, il faut être
conscient que si l'action ocamllex se rappelle récursivement, alors
_menhir_env.lexer.lex_start_p n'est pas le début du token mais une
position quelque part à l'intérieur du token (e.g. après des espaces
blancs). SUGGESTION DE SOLUTION: au lieu de paires (startpos, endpos),
utiliser un type abstrait d'intervalles, avec un traitement particulier
de l'intervalle vide. (Voir mon message du 15/09/2011.)
* Tirer au clair la sémantique des $startpos/$endpos sur les productions vides.
Jacques-Henri dit que $startpos devrait toujours être $endpos du symbole précédent plus les blancs,
et symétriquement pour $endpos. Mais pour implémenter ça il faut consulter la pile?
BUG: %inline ne préserve pas la sémantique de $startpos/$endpos.
* BUG: %inline ne préserve pas la sémantique de $startpos/$endpos.
C'est vrai pour les productions epsilon (forcément)
mais aussi pour des productions non-epsilon
car $startpos de la production inlinée est changée en $endpos(x) où x est le symbole précédent!
Si on gérait les positions par macro-expansion *avant* de faire l'inlining
alors la passe d'inlining n'aurait pas besoin de s'en occuper (et serait
correcte par construction).
* Tenter une minimisation a posteriori de l'automate. Sur la grammaire
OCaml on devrait retrouver l'automate LALR, non?
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment