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: Ashish Agarwal <agarwal1975@g...>
Subject: Re: [Caml-list] Extending modules and signatures
> 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.

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.

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



On Sat, Apr 18, 2009 at 10:20 AM, Martin Jambon
<martin.jambon@ens-lyon.org>wrote:

> Ashish Agarwal wrote:
> > This is a commonly requested feature.
>
> Ah.
>
> > One issue is that a file a.ml
> > <http://a.ml> creates a module A. However, a file a.mli does not create
> > a module type A. I'm not sure why this is the case. Does anyone know if
> > there is a specific reason?
>
> The module type exists, it's just that it doesn't have a name.
>
>  let x = (123, "abc")
>
> does not define "type x = int * string" either.
>
>
>
> Martin
>
> --
> http://mjambon.com/
>