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: | -- (:) |
| 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