J'avais remarqué que les numéros de ligne étaient incorrects, toujours off de
- Je viens de prendre le temps de regarder ça et j'ai une patch que j'aimerais
merger si vous voulez la réviser.
https://gitlab.com/monnier/typer/-/commit/e0d8110c35cd9cdfd69f87233d03c25ac1ca2130
Comments:
commit e0d8110c35cd9cdfd69f87233d03c25ac1ca2130 Author: Simon Génier simon.genier@protonmail.com Date: Wed Feb 16 16:21:53 2022 -0500
Fix off by one error on line numbers.
The source_file object start in a kind of null state, with an empty line, causing to read the first line lazily as the first char is peeked. This means we need to put the cursor before the first line and not on the first line!
The 1st line of the commit message should say which part of the code is affected (like "source.ml" ou qqch comme ça).
Tant qu'à être au nitpicking, j'aime bien distinguer les identifiants de la prose (i.e. la partie qui changerait en cas de traduction à une autre langue), personnellement je le fais avec le `...` de Markdown.
--- a/src/listx.ml +++ b/src/list.ml @@ -1,4 +1,4 @@ -(* Copyright (C) 2021 Free Software Foundation, Inc. +(* Copyright (C) 2021-2022 Free Software Foundation, Inc. * * Author: Simon Génier simon.genier@umontreal.ca * Keywords: languages, lisp, dependent types. @@ -18,6 +18,8 @@ * You should have received a copy of the GNU General Public License along * with this program. If not, see http://www.gnu.org/licenses/. *)
+include Stdlib.List + (* Backport from 4.12. *) let rec equal (p : 'a -> 'a -> bool) (ls : 'a list) (rs : 'a list) : bool = match ls, rs with
Le message de commit n'explique pas pourquoi tu fais ça.
Le changement lui-même est un simple - 1 dans source.ml. Je me suis laissé un peu emporter par les tests, où j'ai ajouté un module pour avoir des bons messages d'erreur quand on compare des listes. Dites-moi si vous aimez, si oui je peux changer pas mal d'autres tests de sexps, lexps, etc pour utiliser ce module et effacer pas mal de code.
Sounds good.
Justement, sur ce sujet, un truc super laborieux en Ocaml est de réécrire pour chaque type une fonction pour les afficher. Je sais qu'on veux éviter les dépendances, mais je viens de me rendre compte de quelque chose.
https://ppxlib.readthedocs.io/en/latest/ppx-for-end-users.html#dropping-ppx-dependencies-with-deriving-inlinePpxlib supporte la génération de code sans dépendances à ppxlib. C'est-à-dire que le code généré va continuer à fonctionner même si on l'enlève, par exemple s'il ne marche plus avec une version future de Ocaml. Qu'est-ce que vous en pensez?
Ça viendrait donc avec un "make target" spécial pour re-construire le code? Ça semble raisonnable. Commençons avec un type.
La raison est que -> est un opérateur, mais n'est-ce pas plus un séparateur comme le = ?
Pour moi, c'est tous des "truc infixes": pas de grosses différence. J'aime aussi briser les fin de lignes avant le `=`, même si je le fais moins souvent.
Mais je ne veux pas imposer de règles trop strictes, il est préférable d'ajuster le style au cas par cas, avec simplement une préférence pour couper les lignes avant les "trucs infixes" (sauf `,` et `;`).
Stefan