English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Extending modules and signatures
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-04-19 (21:46)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Extending modules and signatures
On Sunday 19 April 2009 22:36:12 Ashish Agarwal wrote:
> > The module type exists, it's just that it doesn't have a name.
> Right, thanks for the clarification.
> > let x = (123, "abc")
> > does not define "type x = int * string" either.
> True, but I think the expectations are different for module types. A file
> a.ml creates a module named A, and it seems natural to expect a.mli to
> create a module type A. I find it inconsistent that it does not.

The mli and ml are equivalent to:

  module A : sig =
  end = struct

i.e. no module type is defined.

> Further, if you wanted to name the above type, it is easy, just write "type
> x = int * string". The corresponding solution to naming module types is
> burdensome. You have to define it within another module, introducing an
> unnecessary layer into your module hierarchy. Also that doesn't help you
> when using somebody else's library.

True. There is also an unfortunate amount of copy'n'paste involved as well, 
and manual maintenance of signatures. I believe that often deters people from 
using module signatures and module types at all.

> Having the compiler introduce module type names automatically from mli
> files would be very helpful, and I don't see any disadvantages.

Some people contest the idea that files should automatically convey module 
information at all (SML does not). Indeed, should directories convey 
something as well?

Dr Jon Harrop, Flying Frog Consultancy Ltd.