Comment author: administrator

Alors que class c = ... definit automatiquement un type de classe
correspondant, evitant d'avoir a ecrire class type c = ... a la
main, module M = ... ne le fait pas.

Comme il me semble que cette information est disponible de facon
interne (on a besoin de connaitre le type du module de toutes facons),
ne pourrait-on pas la rendre accessible dans la syntaxe.

Sans vouloir donner l'impression de critiquer les mécanismes de
classes d'OCaml, je préfère pour les modules garder une distinction
nette entre module et type de module, et la laisser bien apparente aux
utilisateurs. Du genre: un module est défini par "module M = ...",
un type de module par "module type MTY = ...", et rien d'autre.
C'est vrai que cela peut augmenter la verbosité du code, mais j'espère
que cela aide aussi à sa compréhension :-)

• Xavier

Comment author: administrator

From: Xavier Leroy xavier.leroy@inria.fr

Alors que class c = ... definit automatiquement un type de classe
correspondant, evitant d'avoir a ecrire class type c = ... a la
main, module M = ... ne le fait pas.

Comme il me semble que cette information est disponible de facon
interne (on a besoin de connaitre le type du module de toutes facons),
ne pourrait-on pas la rendre accessible dans la syntaxe.

Sans vouloir donner l'impression de critiquer les mécanismes de
classes d'OCaml, je préfère pour les modules garder une distinction
nette entre module et type de module, et la laisser bien apparente aux
utilisateurs. Du genre: un module est défini par "module M = ...",
un type de module par "module type MTY = ...", et rien d'autre.
C'est vrai que cela peut augmenter la verbosité du code, mais j'espère
que cela aide aussi à sa compréhension :-)

Sauf que, alors qu'un .mli definit clairement une signature, il
n'existe actuellement aucun moyen de la recuperer en tant que telle.
On en viendrait a` envier SML, ou on definit systematiquement un
signature avant de definir la structure correspondante, ce qui fait
qu'on a toujours la signature sous la main.

Donc, meme sans chercher a pousser la symmetrie avec les classes (qui, il est vrai definissent vraiment beaucoup de choses d'un coup), il y a quelque chose a faire pour simplifier la vie des programmeurs.
Methode un peu violente, un .mli pourrait definir une signature du
meme nom, qui deviendrait la signature du .ml correspondant.

Jacques

Comment author: administrator

While foo.ml defines implicitly a module named Foo, foo.mli does not define
implicitly a module type named Foo. I (Xavier) prefer it this way by fear of
increasing the frequent confusion between modules and module types.