Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
POTTIER Francois
menhir
Commits
83d6e7d5
Commit
83d6e7d5
authored
Aug 26, 2015
by
POTTIER Francois
Browse files
Move up two TODO items.
parent
6effc2d7
Changes
1
Hide whitespace changes
Inline
Side-by-side
TODO
View file @
83d6e7d5
...
...
@@ -94,6 +94,33 @@
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.
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?
Faire cette minimisation *après* la résolution des conflits afin que
...
...
@@ -137,33 +164,6 @@
les paramètres effectifs sont toujours des atomes (symboles terminaux ou
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
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
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment