Browse thread
Extending modules and signatures
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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 ... 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