From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q1NA6JJ1013825 for ; Thu, 23 Feb 2012 11:06:19 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAAUPRk/RVdS2kGdsb2JhbAA7CbJQCCIBAQEBCQkNBxQEI4FzAQEBBBICLAEbDw4BAwwGBQsNLiIBEQEFARwGEwgaolMKi3KCcYUZP4hzAgULiVSDUQ8EBQILAggDAgUDBwYPCAKFFoQmBJU4hxeHFj2EBA X-IronPort-AV: E=Sophos;i="4.73,469,1325458800"; d="scan'208";a="145580216" Received: from mail-wi0-f182.google.com ([209.85.212.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Feb 2012 11:06:14 +0100 Received: by wibhn14 with SMTP id hn14so1053820wib.27 for ; Thu, 23 Feb 2012 02:06:14 -0800 (PST) Received-SPF: pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.82.201 as permitted sender) client-ip=10.216.82.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.82.201 as permitted sender) smtp.mail=gabriel.scherer@gmail.com; dkim=pass header.i=gabriel.scherer@gmail.com Received: from mr.google.com ([10.216.82.201]) by 10.216.82.201 with SMTP id o51mr444170wee.6.1329991574292 (num_hops = 1); Thu, 23 Feb 2012 02:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=QrS6OU1QkyQ1OktovUno0b9rpIwCxESJKBbrFEwmReo=; b=TIDQiBstKnrDugXizb3mk6wW7iRkF/vaypFJ9A3G7K6Lf8Q5xSD9EAh7EZk1N2vwl0 B098xx+T1aY94mgKTdLZ/kDRYRGmBQEnHcoIzU0Okd20QVzL+3Wx0lYm0v9Z1D4r1HXl rlT+hLyDmF6OYamCI2hlubd60XvI0+1W1KgnY= Received: by 10.216.82.201 with SMTP id o51mr363407wee.6.1329991574196; Thu, 23 Feb 2012 02:06:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.63.13 with HTTP; Thu, 23 Feb 2012 02:05:34 -0800 (PST) In-Reply-To: <823246DB-16D0-45CB-953A-3283CA077869@math.nagoya-u.ac.jp> References: <5C609F89-8739-4280-A6D9-3F78C451E0C1@mpi-sws.org> <823246DB-16D0-45CB-953A-3283CA077869@math.nagoya-u.ac.jp> From: Gabriel Scherer Date: Thu, 23 Feb 2012 11:05:34 +0100 Message-ID: To: Ashish Agarwal Cc: Andreas Rossberg , caml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q1NA6JJ1013825 Subject: Re: [Caml-list] Re: "module type of" on sub-module of functor result Apologies for muddling the water here: I'm not a module system expert (but working on it;) and my description was not technically accurate. Thanks Andreas and Jacques for the correction. In the meantime, here is a nicer workaround for you Ashish: (* instead of representing the signature of MapLabels below directly, we build a functor that returns the image signature *) module MAPLABELS (Ord : BatInterfaces.OrderedType) = struct module M = BatMap.Make(Ord) module type S = module type of M.Labels end module MapLabels = struct module Make (Ord : BatInterfaces.OrderedType) : MAPLABELS(Ord).S = struct module M = BatMap.Make(Ord) include M.Labels end end module Test = MapLabels.Make(String) module MS = BatMap.Make(String) (* Test.t and MS.t are compatible, thanks to applicative functors *) let test = Test.add ~key:"foo" ~data:1 MS.empty On Thu, Feb 23, 2012 at 12:17 AM, Jacques Garrigue wrote: > On 2012/02/23, at 3:49, Andreas Rossberg wrote: > >> On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote: >>>> [A(B)] and  [A.B] are syntacticly valid module_expr's but >>>> [A(B).C] isn't. Is this because of an inherent limitation in the >>>> module system? >>> >>> I believe so. When you apply a functor, you may get fresh types as a >>> result -- the generative (abstract, algebraic) types of the functor >>> image. If you write `module M = A(B)`, the fresh types have a clear >>> identity: M.t, M.q etc; similarly if you pass A(B) to a functor with >>> formal parameter X, it is X.t, X.q etc. But if you write `module M = >>> A(B).C`, there is no syntactic way to name the fresh types generated >>> by the functor application; in particular, naming them A(B).t would be >>> incorrect -- because you could mix types of different applications. >>> >>> For example, what would be the signature of A(B).C with: >>> >>> module B = struct end >>> module A(X : sig end) = struct >>>   type t >>>   module C = struct type q = t end >>> end >>> >>> ? >> >> Are you perhaps thinking of SML-style generative functors here? Because with Ocaml's applicative functors F(A) in fact always returns the same abstract types, and you _can_ actually refer to types via the notation F(A).t ;-) > > This is not strictly correct, because of the possibility of avoidance. > I.e. you are allowed to apply a functor to a structure rather than a path, and in that case the behavior of the functor becomes generative, > so the problem described by Gabriel really applies in that case. > > Going back to the question of "module type of", it is currently implemented by typing the module expression in the usual way. > So extending it to a stronger form of module expression would require changing that, and introduce extra complexity. > Doable, but don't hold your breath... > > Jacques Garrigue >