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