TODO

* 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

* autoriser %token FOO (unused)
  (syntaxe concrète à déterminer)
  équivalent à --unused-token FOO sur la ligne de commande.

* BUG: --infer does not work when a non-terminal begins
  with a lowercase letter (Maxime Dénès).

* bench/Makefile no longer works on my Mac? (egrep problem)

* Document anonymous rules.
  Produce well-chosen (predictable) names for anonymous rules.
  In the standard library, possibly rename "anonymous" and "embedded"
  and document them. The non-inline version allows embedding an action in the
  middle of a rule.

* Should we always avoid querying the lexer before a default reduction?
  Would that be difficult/possible? Would that help people who want to
  trigger changes in the lexer?

* Produce well-chosen (predictable) names for anonymous rules?

* ErrorReporting: experiment with merging several symbols
  so as to reduce the noise (e.g. operators, expressions,
  etc.). Or just print the same way, but don't quotient
  internally, as the locations are not the same.

  Also, sort the explanations by a certain measure of
  complexity. E.g., those that go back to a "higher" non-terminal
  symbol should be preferred. Or those that go back further away
  in the buffer?

  Think about HTML output with mouse-over. Or mouse-click.
  Find a way of solving the scrolling problems.
    <pre> and <table> side by side, each with its scroll bar,
    would be nice.

* Add left-recursive lists to the standard library.

* Define [print_result].
  Define a printer that shows the states in the stack.
  Try computing a set of expected symbols in the current state.

* Generate default printers for terminal and nonterminal.
  Using modular implicits, generate terminal2token and
  nonterminal2value.

* IncrementalEngine: document [lr1state], [element], [view].
  Document the Inspection interface.

* document that --depend may produce inaccurate dependencies
  for parser.cmi and that it is recommended to use --raw-depend
  --ocamldep "ocamldep -modules" and work from there (which is
  what ocamlbuild does).

* Confirm and understand why the code back-end slows down by 50%
  between 4.01.0 and 4.02.1. Use the tag last309 for this purpose,
  or the master branch.

* Suite des patchs de Frédéric Bour.
    API d'inspection complète.
      Exposer le nombre d'états (pour la mémoisation) et une conversion état -> entier.
      Idem pour les productions.
    Librairie(s) pour la gestion des erreurs.
    Librairie pour la complétion du parsing.
      Need a way of feeding the parser a nonterminal symbol.
      Or a way of applying a semantic action to a vector of semantic values.
    Peut-on faire un noyau de Merlin indépendant de la grammaire?

* Meilleurs messages d'erreur de syntaxe.
    Revenir en arrière après une erreur, car l'erreur
    n'est détectée qu'après quelques réductions. Une fois que l'on est
    revenu, on peut examiner les items de l'état courant et donner des
    positions de début d'item qui devraient être intéressantes.    
  Possibilité de coloriser ce qu'on a lu en indiquant ce qu'on a compris
  (sortie HTML).

* Test and document --lalr (maybe). Explain that it is (probably)
  incompatible in principle with --explain. Modify the code to fail
  gracefully when the problem arises.

* 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
  la minimisation n'affecte pas le comportement de l'automate, même en
  présence de directives de priorité. Du coup si on combine --canonical
  et --minimize alors on devrait obtenir un automate correct, proche de
  IELR, voir Denny et Malloy. Confirmer.

* Pourquoi --canonical --table ne marche pas sur une grosse grammaire?
  (3m57 pour ocaml.mly versus 16s sans --table)
  Afficher combien de temps est passé à comprimer les tables.

* TableBackend en principe ne devrait pas avoir besoin de Invariant?
  Gain de temps/simplicité possible.

* Could we avoid listing the contents of MenhirLib in 4 different files?

* bundle the Coq library with menhir, and add demos/calc-coq
  to show how it is used

* Clarifier si ocamlbuild doit recevoir -use-ocamlfind, -no-ocamlfind,
  ou rien; tester en particulier sous Windows?
  Modifier la doc pour recommander ocamlfind.

* ajouter une possibilité de désactiver certains warnings (utile pour
  le cours de compilation où on démarre avec une grammaire à trous),
  par exemple les non-terminaux inaccessibles

* move to a new license (GPL V2?), as per Hongbo Zhang's request.
* Les fichiers dans demos/ ne devraient pas être sous QPL mais libres...

* _stage2/menhir.native --interpret fancy-parser.mly
  crashes with Stack_overflow when the input is just "grammar:\n"
  ... it seems to loop now ...

* BUG: la directive $type<...> nt donne lieu à un message d'erreur bizarre
  si le non-terminal nt n'existe pas. (Jacques-Henri.)

* On pourrait rendre moins restrictif le critère qui garantit la terminaison
  de l'expansion des non-terminaux paramétrés. Il suffirait de vérifier que
  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
  `wrapping', d'où risque de `double wrapping' pour un utilisateur qui veut
  alterner entre code et table. On devrait exposer nous-mêmes les deux API.
  En profiter pour laisser l'utilisateur contrôler comment un token doit
  être emballé en `fat token' (token + range).

* %inline pourrait-il fonctionner quand la règle à inliner utilise des $i?
* %inline pourrait-il fonctionner quand les productions à inliner ont un %prec?
    (ça aurait un sens au moins quand on inline dans une production unité?)
    (ou plus généralement quand on inline en dernière position?)

* Reconnaître les directives # n "foo" dans le fichier .mly et en tenir
  compte dans les locations.

* BUG: message de Valentin Gatien-Baron du 09/01/2010: le bug de --explain
  est-il bien le bug connu? peut-on le corriger? ne suffirait-il pas de
  passer sous silence les conflits qui ont lieu dans une partie inaccessible
  de l'automate?

* BUG: message de Valentin Gatien-Baron du 09/01/2010: le warning erroné à
  propos d'un %prec inutile peut-il être évité?

* Implémenter un test de détection de boucles. Si la grammaire contient une
  boucle, elle est infiniment ambiguë. Pour le test, calculer tous les
  nullables, ajouter une production unité A -> B dès qu'il existe une
  production A -> alpha B beta avec alpha et beta nullables, et regarder
  ensuite s'il existe un cycle de productions unité.

* Permettre une trace avec autre chose que fprintf stderr. Cela permettrait
  au programmeur (par exemple) de décider à runtime s'il veut afficher ou
  non la trace.

* (petit) BUG: --follow-construction n'affiche pas le contenu des états
  initiaux (r0)

* relire la preuve de Pager et comprendre si ce que fait Lr1.grow est correct
  ou pas; faut-il faire grossir les états existants, ou bien (par exemple) les
  supprimer et recommencer leur construction?

* que fait/que doit faire la combinaison --tokens-only --depend?

* Préserver dirname/ dans les directives #line émises.

* BUG: Boris (1.- bouclage parser sur une entrée erronée 2.- une lecture
  trop loin dans le stream, également liée à error).

* éviter "Warning: 22 conflicts ..." car emacs prend "Warning" pour un
  nom de fichier; d'après Damien, il devrait suffire que la phrase après
  les deux points ne commence pas par un nombre.

* ajouter une option -q pour désactiver tous les warnings

* si une variable est inutilisée dans une action sémantique, le
  warning est affiché dans le code produit.

* BUG: solving a shift/reduce conflict in favor of reduction can
  cut a path that was required in order to explain another conflict.
  (see e.g. belloeil.mly) (et le reduced_parser.mly d'Adrien Guatto)
  Or just give up on explaining the conflict in this case.
  Take priorities into account *during* the construction of the
  automaton? Is it feasible? Compatible with Pager?

* BUG: cutdown.mly

* le fichier .conflicts devrait etre supprime par --explain s'il
  n'y a aucun conflit

* dans le dump de l'automate, rajouter les transitions qui ont
  ete supprimees par resolution de conflits. Afficher aussi les
  réductions par défaut?

* expliquer aussi les conflits end-of-stream

* Documenter l'emploi d'ocamlbuild.

* Lorsqu'on crée un pseudo-lexème pour utiliser dans les
  directives %prec, la question de savoir s'il est associatif
  à gauche ou à droite ou pas du tout ne se posera jamais. Donc,
  pour faire propre, on ne devrait pas autoriser l'emploi de
  %left, %right, %nonassoc (sauf pour compatibilité arrière,
  avec warning) mais introduire un nouveau mot-clé %fictitious
  ou %pseudo ou whatever.

* Autre remarque du même tonneau, si on souhaite choisir un
  niveau mais pas un statut d'associativité (parce qu'on pense
  qu'il est inutile), il faudrait pouvoir déclarer %neutral
  (whatever) et obtenir un niveau au statut non-spécifié (d'où
  erreur si on tente de consulter ce statut).

* Prévoir une sortie --ocamlyacc qui affiche la grammaire sans
  les liaisons des valeurs sémantiques et sans les actions
  sémantiques?

* Faire le nécessaire pour empêcher les warnings d'ocaml 3.09
  sur les valeurs sémantiques nommées et non utilisées? Le
  problème est que l'erreur est forcément rapportée dans le
  fichier .ml engendré. Et ça résoudrait le problème du cas
  où on n'utilise que $startpos(v) et pas v.

* Il faudrait activer le warning qui recommande d'utiliser --infer
  dès que la librairie standard est utilisée (et pas seulement lorsque
  %inline est utilisé).