> Je l'avais introduit quand j'ai changé le comportement, mais oui, je ne crois
> pas qu'on va vouloir revenir au comportement antérieur, donc on peut
> l'éliminer.
Super, ça va me simplifier la vie.
> > - Séparer le cas des séparateurs (dont la précédence est la même) des
> > opérateurs binaires.
> 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 `|`.
> > Lancer une erreur pour les opérateurs binaires qui n'ont pas leurs
> > deux arguments.
> C'est déjà le cas comme tu l'as vu:
> expected: Int
> but expression has type: Unit
> Je ne pense pas que ce soit une bonne idée de le considérer comme une
> erreur au niveau `sexp`. Je préfère retarder cette décision
> à l'élaboration.
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 (...) | ...
Simon