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.5 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 77B85BBAF for ; Sun, 19 Apr 2009 23:46:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAHY460nUnwcjjmdsb2JhbACCHZQcAQEBAQkLCAkPBrUxg30G X-IronPort-AV: E=Sophos;i="4.40,213,1238968800"; d="scan'208";a="24826835" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Apr 2009 23:46:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFADo460nUnw4T/2dsb2JhbACCHcoHg30G Received: from pih-relay06.plus.net ([212.159.14.19]) by relay.ptn-ipout01.plus.net with ESMTP; 19 Apr 2009 22:46:24 +0100 Received: from [87.115.105.35] (helo=leper.local) by pih-relay06.plus.net with esmtp (Exim) id 1LveqG-0002Kp-EY for caml-list@yquem.inria.fr; Sun, 19 Apr 2009 22:46:24 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Extending modules and signatures Date: Sun, 19 Apr 2009 22:53:13 +0100 User-Agent: KMail/1.9.9 References: <49E9E195.6030603@ens-lyon.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904192253.13453.jon@ffconsultancy.com> X-Plusnet-Relay: 0a4ec4d168eaa323d13beacc76ad461c X-Spam: no; 0.00; mli:01 mli:01 sig:01 struct:01 compiler:01 2009:98 frog:98 sml:01 wrote:01 signatures:01 signatures:01 naming:01 caml-list:01 int:01 int:01 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