C'est déjà le cas, non?
Non, Typer ne considère que la priorité de droite de l'opérateur précédent. Par exemple, le `case` de `case_|_` est traité de la même façon que le `|`.
T'es sûr? Tu peux donner un exemple?
J'aurais du spécifier une erreur utile :). C'est vrai que c'est mieux de gérer toutes les erreurs à cette étape. Idéalement, ce qu'on veut, c'est un objet erreur dans le `sexp` pour pouvoir reconstruire l'erreur d'analyse syntaxique lors de l'élaboration. Dans notre cas, `dummy_epsilon` agit un peu comme ça, mais ne contient aucune donnée. Pensez-vous que ça vaudrait la peine d'avoir un constructeur `Error of location * reason` dans `sexp`, où
type reason = Missing_lhs of (...) | ...
Mon espoir est que c'est pas forcément toujours une erreur. E.g. `(_+_ () 4)` ne devrait pas signaler une erreur du tout, mais devrait à la place être reconnu comme un usage du "unary plus".
Le "dummy_epsilon" *est* justement une représentation d'une erreur d'un argument manquant, mais sans le jugement "c'est une erreur" vu qu'à ce stade on ne sait pas si ça le sera.
De manière générale, autant l'analyse lexicale que syntaxique ne devraient presque jamais signaler d'erreur. À la place, les erreurs "de syntaxe" sont reconnues pendant l'élaboration.
Stefan