Commit 83d6e7d5 authored by POTTIER Francois's avatar POTTIER Francois

Move up two TODO items.

parent 6effc2d7
...@@ -94,6 +94,33 @@ ...@@ -94,6 +94,33 @@
incompatible in principle with --explain. Modify the code to fail incompatible in principle with --explain. Modify the code to fail
gracefully when the problem arises. 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.
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 * Tenter une minimisation a posteriori de l'automate. Sur la grammaire
OCaml on devrait retrouver l'automate LALR, non? OCaml on devrait retrouver l'automate LALR, non?
Faire cette minimisation *après* la résolution des conflits afin que Faire cette minimisation *après* la résolution des conflits afin que
...@@ -137,33 +164,6 @@ ...@@ -137,33 +164,6 @@
les paramètres effectifs sont toujours des atomes (symboles terminaux ou les paramètres effectifs sont toujours des atomes (symboles terminaux ou
non-terminaux), non? (Jacques-Henri.) non-terminaux), non? (Jacques-Henri.)
* 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.
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).
* En mode code on tire les tokens d'un lexbuf et l'utilisateur doit construire * En mode code on tire les tokens d'un lexbuf et l'utilisateur doit construire
l'API moderne par `wrapping', s'il la souhaite. Mais en mode table l'API l'API moderne par `wrapping', s'il la souhaite. Mais en mode table l'API
moderne est native et l'API traditionnelle est construite (par nous) par moderne est native et l'API traditionnelle est construite (par nous) par
......
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