From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 98D44BBAF for ; Mon, 20 Apr 2009 02:09:56 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUAAPpZ60lCbwQZkWdsb2JhbACWOQEBAQEJCwoHEQS0cIN9Bg X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="27933943" Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 Apr 2009 02:09:56 +0200 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0700D31ED75; Sun, 19 Apr 2009 20:09:55 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 19 Apr 2009 20:09:55 -0400 X-Sasl-enc: IAM2Gvvk2iiSKNBXJsCU3Tw7m/SDIRJQ7C713zhVQVnR 1240186194 Received: from [192.168.1.10] (ALyon-157-1-146-133.w90-42.abo.wanadoo.fr [90.42.153.133]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4B19F2C0C6; Sun, 19 Apr 2009 20:09:54 -0400 (EDT) Message-ID: <49EBBC6C.8000502@ens-lyon.org> Date: Mon, 20 Apr 2009 02:06:04 +0200 From: Martin Jambon User-Agent: Thunderbird 2.0.0.17 (X11/20081008) MIME-Version: 1.0 To: Ashish Agarwal Cc: Peter Hawkins , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Extending modules and signatures References: <49E9E195.6030603@ens-lyon.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ens-lyon:01 mli:01 compiler:01 mli:01 module's:01 functor:01 sig:01 val:01 struct:01 struct:01 wrote:01 signatures:01 signatures:01 naming:01 caml-list:01 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. > > 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/