Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
M
menhir
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
12
Issues
12
List
Boards
Labels
Service Desk
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Packages & Registries
Packages & Registries
Container Registry
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
POTTIER Francois
menhir
Commits
83d6e7d5
Commit
83d6e7d5
authored
Aug 26, 2015
by
POTTIER Francois
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Move up two TODO items.
parent
6effc2d7
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
27 additions
and
27 deletions
+27
-27
TODO
TODO
+27
-27
No files found.
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
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a 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