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
Afficher les réponses par date
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
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.
Ok, je vois. Donc idéalement, `_+_` serait un macro qui détecterait le ε. Je pense quand même que le ε devrait contenir plus d'information pour permettre au macro de donner un message d'erreur potable, mais c'est probablement une tâche pour une autre fois.
Sinon, voici la branche qui continent les changements pour que les `Node`s aient la location de tous leurs composantes et non pas juste celui de la tête. Elle est prête si vous voulez la réviser.
https://gitlab.com/monnier/typer/-/tree/simon--sexp-node-location
Aussi, j'allais rebaser la branche pour l'amélioration du logging. Je voulais regarder si ce serait plus facile de merger celle pour finaliser les sinfo en premier. Quel est le nom de la branche déjà? Est-ce que c'est `location-sinfo` et est-ce qu'elle est encore à jour?
Simon
Sinon, voici la branche qui continent les changements pour que les `Node`s aient la location de tous leurs composantes et non pas juste celui de la tête. Elle est prête si vous voulez la réviser.
T'as tendance à faire beaucoup de changements cosmétiques en même temps que les vrais changements. Ça rendra les merge futurs vraiment pénibles.
Stefan
-
Simon Génier -
Stefan Monnier