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 q1NEUQdv022879 for ; Thu, 23 Feb 2012 15:30:26 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQBAApNRk9KfVK2kGdsb2JhbAA7CbJECCIBAQEBBwsNBxQEI4FzAQEBAwESAiwBGw8OAQMBCwYFCw0uIQEBEQEFARwGEyKHX5tGCotygnGFGz+IcwIFC4h0YIQLEQEMhGsBKgp2gzAElTiHF4QAgxY9hAM X-IronPort-AV: E=Sophos;i="4.73,470,1325458800"; d="scan'208";a="145632747" Received: from mail-we0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Feb 2012 15:30:20 +0100 Received: by werm13 with SMTP id m13so1361449wer.27 for ; Thu, 23 Feb 2012 06:30:20 -0800 (PST) Received-SPF: pass (google.com: domain of agarwal1975@gmail.com designates 10.180.109.225 as permitted sender) client-ip=10.180.109.225; Authentication-Results: mr.google.com; spf=pass (google.com: domain of agarwal1975@gmail.com designates 10.180.109.225 as permitted sender) smtp.mail=agarwal1975@gmail.com; dkim=pass header.i=agarwal1975@gmail.com Received: from mr.google.com ([10.180.109.225]) by 10.180.109.225 with SMTP id hv1mr3769993wib.6.1330007420632 (num_hops = 1); Thu, 23 Feb 2012 06:30:20 -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; bh=GDvsRp3OZnF6en84S6qxVj4zD2/HRdW9mMTK7ELOMPo=; b=CI+vqxAbQ6sjGInRbnIP2+v1hBFFjgFKgx5CXJQ1co3Tg3BMmlNQbsSPX8LnbNBuQl pZkhtxm21DP0KFJdi2TIN+LoqHYdop5lqh+rE5TqhQZ0RUoBgvedk4Nnl3/esjygSLhf 4OgZNccKSYC/lwFlOAeNrh/DTmlL/k+0X/Pa8= Received: by 10.180.109.225 with SMTP id hv1mr3083630wib.6.1330007420568; Thu, 23 Feb 2012 06:30:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.39.148 with HTTP; Thu, 23 Feb 2012 06:30:00 -0800 (PST) In-Reply-To: References: <5C609F89-8739-4280-A6D9-3F78C451E0C1@mpi-sws.org> <823246DB-16D0-45CB-953A-3283CA077869@math.nagoya-u.ac.jp> From: Ashish Agarwal Date: Thu, 23 Feb 2012 14:30:00 +0000 Message-ID: To: Gabriel Scherer Cc: Andreas Rossberg , caml List Content-Type: multipart/alternative; boundary=e89a8f2354bbda065304b9a27b73 Subject: Re: [Caml-list] Re: "module type of" on sub-module of functor result --e89a8f2354bbda065304b9a27b73 Content-Type: text/plain; charset=ISO-8859-1 Thanks for all the helpful replies. On Thu, Feb 23, 2012 at 10:05 AM, Gabriel Scherer wrote: > 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 > > > --e89a8f2354bbda065304b9a27b73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for all the helpful replies.

On Th= u, Feb 23, 2012 at 10:05 AM, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
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:

=A0(* instead of representing the signature of MapLabels below directly, =A0 =A0 we build a functor that returns the image signature *)
=A0module MAPLABELS (Ord : BatInterfaces.OrderedType) =3D struct
=A0 =A0module M =3D BatMap.Make(Ord)
=A0 =A0module type S =3D module type of M.Labels
=A0end

=A0module MapLabels =3D struct
=A0 =A0module Make (Ord : BatInterfaces.OrderedType) : MAPLABELS(Ord).S = =3D struct
=A0 =A0 =A0module M =3D BatMap.Make(Ord)
=A0 =A0 =A0include M.Labels
=A0 =A0end
=A0end

=A0module Test =3D MapLabels.Make(String)
=A0module MS =3D BatMap.Make(String)
=A0(* Test.t and MS.t are compatible, thanks to applicative functors *)
=A0let test =3D Test.add ~key:"foo" ~data:1 MS.empty

On Thu, Feb 23, 2012 at 12:17 AM, Jacques Garrigue
<garrigue@math.nagoya-u.= ac.jp> 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 =A0[A.B] are syntacticly valid module_expr'= s but
>>>> [A(B).C] isn't. Is this because of an inherent limitat= ion in the
>>>> module system?
>>>
>>> I believe so. When you apply a functor, you may get fresh type= s as a
>>> result -- the generative (abstract, algebraic) types of the fu= nctor
>>> image. If you write `module M =3D A(B)`, the fresh types have = a clear
>>> identity: M.t, M.q etc; similarly if you pass A(B) to a functo= r with
>>> formal parameter X, it is X.t, X.q etc. But if you write `modu= le M =3D
>>> A(B).C`, there is no syntactic way to name the fresh types gen= erated
>>> by the functor application; in particular, naming them A(B).t = would be
>>> incorrect -- because you could mix types of different applicat= ions.
>>>
>>> For example, what would be the signature of A(B).C with:
>>>
>>> module B =3D struct end
>>> module A(X : sig end) =3D struct
>>> =A0 type t
>>> =A0 module C =3D struct type q =3D t end
>>> end
>>>
>>> ?
>>
>> Are you perhaps thinking of SML-style generative functors here? Be= cause with Ocaml's applicative functors F(A) in fact always returns the= same abstract types, and you _can_ actually refer to types via the notatio= n 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 p= ath, 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 curren= tly 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
>

--e89a8f2354bbda065304b9a27b73--