Re: [Caml-list] Extending modules and signatures

[Ashish Agarwal <agarwal1975@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

> I think the real issue is inheritance.
Yes. Your example adds an extra complication by using references. Forgoing
that, I get around this within the current module system by defining a base
module B, which two other modules C an D "inherit", i.e. they just include
B. Module B has the common values and types needed by C and D. Only problem
with this is that I am forced to expose all the values and types in B to all
client code. It would help to restrict B's visibility to just C and D. No
big deal for internally used libraries; I just remember not to use B
elsewhere. However, it is not a good solution for libraries distributed to
others.


On Sun, Apr 19, 2009 at 8:06 PM, Martin Jambon
<martin.jambon@ens-lyon.org>wrote:

> 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/
>

[-- Attachment #2: Type: text/html, Size: 3767 bytes --]