From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q489rbME009662 for ; Tue, 8 May 2012 11:53:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukBAOLrqE+LEwExe2dsb2JhbABEFrMPIgEBFiYFIoIMAQEBAgInCwENAQE3AQ8FBhguITYGExEDh2wDCwunH4QxAYYBDYlNBooahnKWAos/h24 X-IronPort-AV: E=Sophos;i="4.75,549,1330902000"; d="scan'208";a="142914256" Received: from hera.mpi-sb.mpg.de ([139.19.1.49]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 08 May 2012 11:53:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-ID:In-Reply-To: References:Date:Subject:From:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=pyzI3hN30ImxNn3wUD6TtVBDD64em8Sm3r xwMkq8Oxk=; b=YOAwAhe4n8/fcT1o2QBInOzdZOW09OiE+kmN0MCB4jHpmfdLVJ AeW5UWuh7RYt0nuUgIy/kKyLZeuFRJmXiKtrU6RDKot6kyAh7HNsijNySvCF8bov QwA2CjZRlaaGkLKBMPln8mZnyrqQx/XgO8yNQfHfTms7Q9nscBohJh2Mw= Received: from srv-00-125.mpi-klsb.mpg.de ([139.19.1.28]:55421 helo=maniac.mpi-klsb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1SRh6i-0000Vc-9l; Tue, 08 May 2012 11:53:29 +0200 Received: from local by maniac.mpi-klsb.mpg.de (envelope-from ) with local (Exim 4.72) id 1SRh6h-0001xh-Q8; Tue, 08 May 2012 11:53:24 +0200 Received: from 74.125.57.233 (SquirrelMail authenticated user rossberg) by mail.mpi-sws.org with HTTP; Tue, 8 May 2012 11:53:24 +0200 Message-ID: In-Reply-To: References: Date: Tue, 8 May 2012 11:53:24 +0200 From: rossberg@mpi-sws.org To: "Gabriel Scherer" Cc: coste@irit.fr, caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Caml-list] reuse of abstract types "Gabriel Scherer" wrote: >> Now I want to design a module Q, with operations using type t. To refer to >> t in >> the signature of Q, I am obliged to declare a module Mt : MT inside the >> signature >> >> module type QT = sig >>  module Mt : MT >>  val g : Mt.t -> .... >> end > > I don't believe this is the way to go. Actually, there is nothing wrong with coste's approach. In fact, that is the way advocated by some in the ML modules community (see e.g. Part III on modules in Bob Harper's SML book, http://www.cs.cmu.edu/~rwh/smlbook/book.pdf). One advantage is that it makes signatures more self-contained. Others prefer the more "lightweight" approach of only putting in the types, like you suggest. It works well, too, but can get more tedious when you are dealing with modules exporting several types, or with several modules exporting types of conflicting names. /Andreas