Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
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
    ...
  end

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.
http://www.ffconsultancy.com/?e