Génier Simon [2021-05-13 01:59:11] wrote:

Salut,

J'ai un autre changement à faire réviser dans ma saga de locations. Celui-ci déplace la gestion des lignes et des colonnes à l'intérieur de l'objet source. L'avantage n'est peut-être pas évident dans cette patch, mais je vous promet que j'en ai une autre qui change le module Lexer pour utiliser l'objet source. Ce simplifie de beaucoup cette phase parce qu'on réutilise justement ce code qui gère les lignes et les colonnes.

https://gitlab.com/monnier/typer/-/compare/master...source-tells-its-own-location

Ça sonne bien, mais je comprends pas pourquoi t'as besoin de dupliquer le test de utf8-head: il semble que tu ajoutes une définition redondante de `is_utf8_head` d'une part et que tu gardes un `inc_cp` dans `lexer.ml` sans l'utiliser pour faire le même travail dans le `advance` de `source.ml`. IOW, j'ai l'impression que le changement est incomplet.

Sinon, je voulais vous partager mes idées pour les docstr. En ce moment on les attache à la location du prochain token. C'est un peu bizarre, parce que les tokens peuvent tous recevoir une location, mais en fait pour la plupart on ignore silencieusement leur docstr.

Yup.

En fait, ce qu'on veut vraiment, c'est d'attacher ces commentaires à une déclaration. Ma proposition est donc d'ajouter à chaque entrée du contexte un champ qui contient le docstr.

Dans ce cas, il faut aussi ajouter de telles entrées dans les datatypes, vu qu'un module devrait pouvoir porter les docstrings et que les modules sont des tuples. Ça ne me semble pas très prometteur.

J'aimerais bien pouvoir gérer les docstrings sans avoir besoin d'introduire le concept ni dans `sexp`, ni dans `location`, ni dans le contexte. I.e. ça devrait être un concept qui n'apparait pas dans le code OCaml, mais seulement dans le code Typer (i.e. défini par des macros).

Une approche possible à l'heure actuelle est d'utiliser une convention qui transforme par exemple:

myfun x y "This is my doc" = def;

en

myfun x y = def; myfun_docstring = "This is my doc";

2 problèmes: - J'aime pas beaucoup la syntaxe ci-dessus. - L'usage de "concaténer _docstring" est un peu trop ad-hoc. E.g. une redéfinition de `myfun` qui n'a pas de docstring aura tendance à "oublier" de cacher la définition de `myfun_docstring` et on fini avec une docstring qui n'est pas appliquée à la bonne définition. Ceci dit, Common-Lisp vit avec ça, donc c'est pas la fin du monde. C'est pragmatique, simple, et "does the job". Mais disons que c'est clairement plus proche de la philosophie d'ELisp que de celle d'Agda ;-) - Comme nous l'enseignent les "symbol properties" de Lisp, il n'y a pas que les docstrings qu'on peut vouloir associer à certaines définitions, mais il peut y avoir toute sorte d'autres infos. - Il y a aussi des arguments en faveur d'associer une docstring (ou autres info auxiliaire) non pas à l'identifiant mais à la valeur définie. - L'informatique ne serait rien sans les problèmes d'off-by-one (ou 2 ou 3 dans le cas présent).

Stefan