From: Martin Jambon <martin.jambon@ens-lyon.org>
To: Ashish Agarwal <agarwal1975@gmail.com>
Cc: Peter Hawkins <hawkinsp@cs.stanford.edu>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Extending modules and signatures
Date: Mon, 20 Apr 2009 02:06:04 +0200 [thread overview]
Message-ID: <49EBBC6C.8000502@ens-lyon.org> (raw)
In-Reply-To: <d8be5ae20904191436y6e43fa10y6aa0ec6dc2bbdde8@mail.gmail.com>
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 <http://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.
OK, but I think the real issue is inheritance. In order to truly extend an
existing module, one needs to access the private items of the inherited module
implementation. In order to avoid messing up with the original module's
global variables, the inherited "module" should be more like a functor that
would create a fresh instance of the module each time it is instantiated, just
like classes generate objects.
I could imagine something like this:
module class A :
sig
val get_x : unit -> int
end =
struct
let x = ref 123
let get_x () = !x
end
module class B =
struct
inherit A
let incr_x () = incr x
end
module B1 = new module B
module B2 = new module B
;;
B1.incr_x ();;
- : unit = ()
B1.get_x ();;
- : int = 124
B2.get_x ();;
- : int = 123
Module class implementations and signatures could be conveniently created as
whole files using new file extensions, say .mc and .mci. These would be like
.ml files except that they would support module class inheritance and would be
evaluated only when they are instantiated with "new module".
Martin
--
http://mjambon.com/
next prev parent reply other threads:[~2009-04-20 0:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 20:51 Peter Hawkins
2009-04-17 21:36 ` [Caml-list] " Goswin von Brederlow
2009-04-18 5:47 ` Ashish Agarwal
2009-04-18 14:20 ` Martin Jambon
2009-04-19 21:36 ` Ashish Agarwal
2009-04-19 21:53 ` Jon Harrop
2009-04-20 5:17 ` Goswin von Brederlow
2009-04-20 0:06 ` Martin Jambon [this message]
2009-04-20 5:23 ` Goswin von Brederlow
2009-04-20 11:55 ` Martin Jambon
2009-04-21 16:01 ` Ashish Agarwal
2009-04-17 21:30 Dario Teixeira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49EBBC6C.8000502@ens-lyon.org \
--to=martin.jambon@ens-lyon.org \
--cc=agarwal1975@gmail.com \
--cc=caml-list@yquem.inria.fr \
--cc=hawkinsp@cs.stanford.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox