From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id 7CFE25D6 for ; Thu, 20 Sep 2018 16:02:27 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.53,399,1531778400"; d="scan'208,217";a="347330512" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 20 Sep 2018 18:02:25 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 1D6D082506; Thu, 20 Sep 2018 18:02:25 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 7B841824CF for ; Thu, 20 Sep 2018 18:02:19 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=arlencox@gmail.com; spf=Pass smtp.mailfrom=arlencox@gmail.com; spf=None smtp.helo=postmaster@mail-yw1-f54.google.com IronPort-PHdr: =?us-ascii?q?9a23=3Am9BxWxIFgKPxhM/VONmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgQLfvxwZ3uMQTl6Ol3ixeRBMOHs60C07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffwdFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhy?= =?us-ascii?q?gJNzE78G/ZhM9+gr9Frh29vBFw2ZLYbZuPOfZiYq/Qf9UXTndBUMZLUCxBB5ux?= =?us-ascii?q?YpcVD+oFI+lYqZT2qkUJrRqxGAKhA/ngyiVMhnDo2601z+MhEA7d0QwvGtIBqn?= =?us-ascii?q?XUrNHvOKgOVuC1ybDFwDPeZP1VwTfw8JbEfgwlrP2WXr99cdDdxVQuGg/YlFmd?= =?us-ascii?q?qYPoMjWI3eoXqWeb9fBvVee3hm4ntQ5xpj+vy98piobTh4IVzknI9CV3wYooPN?= =?us-ascii?q?G4Rk52bNG+HJtfsCGaMIR2Qsc8TG1ypCk6zbgGtYa6fCgM1psn2wbSZ+Kbf4WM?= =?us-ascii?q?+B7uV+acLS1liH9kZb6znRa//Ee4xu35TMa00VJKriRfktnLs3AAzwbc6tKDSv?= =?us-ascii?q?Rj+EeuxTGP1g/I5+FLJEA7j6vbK5o7zrEskZoTtFzPHjXql0XukK+WakIk9/C0?= =?us-ascii?q?5Ov9Z7XmooaQN4t1igHlLqQjgde/AOQ9MggWRWeX4+W81Lv5/U34WrpGlPM2kr?= =?us-ascii?q?OK+KzdcM8So6r8Bw5Ozq4i7Qy+BnGoyoc2h34CeXtffB+Bx6PuKxmaKer8APG0?= =?us-ascii?q?hESEnzJixvSANbrkVMaeZkPfmavsKO4uo3VXzxA+mIgGtsBkT4oZKfe2YXff8d?= =?us-ascii?q?nRDxs3KQuxmr+1B9B014dYUmWKUPbAbPHi9GSQ7+dqGNGiIZcPsW+kefcg7v/q?= =?us-ascii?q?y3Q+nA1FJPT77d4scHm9W89eDQCZbH7r2IpTFG4Luk8vU7WvhgDeFzFUYHm2Uu?= =?us-ascii?q?Q34TRpUI8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAgDSw6NbhzahVdFSCYQtAYE/KINzg?= =?us-ascii?q?R2CXJBMgg2IbIgmhzYLhGwCg0IZBwEEMxUBAwEBAgEBAQEBEwEBAQgNCQgpIwy?= =?us-ascii?q?CNSKCYgECAgEjHQEbHgMBCwYDAgs3AgIhAQERAQUBHBkbgwaBaQEDDQiIYZAGP?= =?us-ascii?q?IsLgQgJBQEXgnYFg3YKGSYNWIFvAgYSil0XgUE/hCSCVoF+gyuCVwKcQiwJggy?= =?us-ascii?q?LAYMXF48ijF+IBw8hgTeBdzMaCBsVbII7gjODT4puIzCNcgEB?= X-IPAS-Result: =?us-ascii?q?A0DtAgDSw6NbhzahVdFSCYQtAYE/KINzgR2CXJBMgg2IbIg?= =?us-ascii?q?mhzYLhGwCg0IZBwEEMxUBAwEBAgEBAQEBEwEBAQgNCQgpIwyCNSKCYgECAgEjH?= =?us-ascii?q?QEbHgMBCwYDAgs3AgIhAQERAQUBHBkbgwaBaQEDDQiIYZAGPIsLgQgJBQEXgnY?= =?us-ascii?q?Fg3YKGSYNWIFvAgYSil0XgUE/hCSCVoF+gyuCVwKcQiwJggyLAYMXF48ijF+IB?= =?us-ascii?q?w8hgTeBdzMaCBsVbII7gjODT4puIzCNcgEB?= X-IronPort-AV: E=Sophos;i="5.53,399,1531778400"; d="scan'208,217";a="279604781" Received: from mail-yw1-f54.google.com ([209.85.161.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Sep 2018 18:02:18 +0200 Received: by mail-yw1-f54.google.com with SMTP id x67-v6so3972562ywg.0 for ; Thu, 20 Sep 2018 09:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fq+lKKRwJAyQtxhgy2A7zQe3cuSdfhgfB+RM/eQH7O8=; b=YSNob2WPnpOQ6l9SelhmBAcAtDpy1O4n13lL7Sgx8cV3dbOw672AgCXc9Fv6oSC3Vp VuQnW02TAr30uzwqt8LMJznSCFlCdCdVcFczlmfqTC9SJOR9mSIaHMxB3DPH38UzTtVg nTcekDkA+WjBMcC4LEZQtr4d2YxLylzzNPLg4Xoh/muksOhKceW3KC752KIkp+B+RvKQ tMFPKhhaNR/8BbDrcn75ung9bTr1u82m0LeFqS82/Ow/O6wAuwL8jVVLm2oqz5OYDK0i pRkv4lVKG2g9KYG1bpTfWfwEqFbOxhwsaAyxrMyMrLFJW1qz2wi8cKukGi1NUNochhEo wQFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fq+lKKRwJAyQtxhgy2A7zQe3cuSdfhgfB+RM/eQH7O8=; b=C+5YB7tvM3iPhOCoKj67mCNWyyYmMG3Fcv2M4wO5hVqLGlaLOG0EphhTAv6jMU4SFT JBqxfujKc7Q8ZciW/hCVu80ShpgqTdzxgGVBy1WEPr00tueux6MJM66ahbVtp4umKwQ9 vnuaj9DZ+SGPrqEAXAJlHES+ym/uiXCUPBYMV1E3Z8Qd4W4qFTrMs71S5xTfTYwLLerT QWtmtPriqKrzWnCrzBVwbFFAOaKZmwubSjewePVrwvzSSPrh+4JPNWxw5z7hLHrom7Yv Eaa3mPZ/FhbXBD9NKc3nHXn9iY9gyPtl3FFRtzRzFTp423qS600gzW+lEgtNKrJUUUDX VyVA== X-Gm-Message-State: APzg51CV56JDjVE+4JpqWu20OQbAxD4faSQ26nsrVTHJZsK0Xq/NLI9q lWj6vy5R0U1mXXb4o9BUsatMEDrDNUoQJa3Fb/iovPNm X-Google-Smtp-Source: ANB0VdY4JxGrAVKnYLOUsgD3XrxTCuvQfeP38001VBWD3JvbM1hwMSM5o9fI8x6AHF11iQ8h+dTKHwcHbgpidxqXu4w= X-Received: by 2002:a81:240e:: with SMTP id k14-v6mr17503919ywk.58.1537459336058; Thu, 20 Sep 2018 09:02:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arlen Cox Date: Thu, 20 Sep 2018 12:02:04 -0400 Message-ID: To: caml-list@inria.fr Content-Type: multipart/alternative; boundary="00000000000095273305764fa547" Subject: Re: [Caml-list] Applicative Functor Madness Reply-To: Arlen Cox X-Loop: caml-list@inria.fr X-Sequence: 17077 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000095273305764fa547 Content-Type: text/plain; charset="UTF-8" Based on some initial feedback, I'm providing some further information: What I have is a whole bunch of functors that look like this: module Make(S : OrderedType) = struct module SM = Map.Make(S) module SS = Set.Make(S) module SC = CustomFunctor.Make(S) (* where SC has exposed maps and sets in its interface *) ... (* many more similar modules/functors *) ... let foo () : SS.t = SC.run SS.empty end I don't really want to define the type of Make because I have to constrain that SS, SM, and SC all preserve applicative identity in a type constraint. Then I have to do the same thing for every CustomFunctor as well. Worst, it's difficult to tell when things have been broken because exactly which equality is missing is completely opaque in the type checking -- especially when most of the uses of these modules is just plumbing (to preserve applicative identity). Thanks all, Arlen On Thu, Sep 20, 2018 at 10:29 AM Arlen Cox wrote: > Hi everyone, > > I'm having some trouble getting some code that relies heavily on > applicative functors to type check. Does anyone know what I'm doing wrong > with this? > > module type S = sig > module T : Set.OrderedType > module ST : module type of Set.Make(T) > end > > module Make(T_in : Set.OrderedType) : S (* <- ERROR *) > with module T = T_in > and module ST = Set.Make(T_in) > = struct > module T = T_in > module ST = Set.Make(T_in) > end > > I get the following error message referencing the above point in the > program. > > Error: In this `with' constraint, the new definition of ST > does not match its original definition in the constrained signature: > ... > Type declarations do not match: > type t = Set.Make(T_in).t > is not included in > type t = Set.Make(T).t > File "set.mli", line 68, characters 4-10: Expected declaration > File "set.mli", line 68, characters 4-10: Actual declaration > > It seems to me that since T = T_in, but applicative functors should make > the type of Set.Make(T) = Set.Make(T_in). Does this not work this way? > > Note that if I change the definition of S slightly, the same definition of > Make now type checks: > > module type S = sig > module T : Set.OrderedType > module ST : Set.S with type elt = T.t > end > > This solution is undesirable because I have a number of modules whose > types would require an excessive number of "with module ... = ..." > constraints to constrain in this way. Is there a better way of getting > this to type check? > > Thank you, > Arlen > > > -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs --00000000000095273305764fa547 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on some initial feedback, I'm providing som= e further information:

What I have is a whole= bunch of functors that look like this:

module Mak= e(S : OrderedType) =3D struct
=C2=A0 module SM =3D Map.Make(S)
=C2=A0 module SS =3D Set.Make(S)
=C2=A0 module SC =3D Cus= tomFunctor.Make(S)
=C2=A0 (* where SC has exposed maps and sets i= n its interface *)
=C2=A0 ...
=C2=A0 (* many more s= imilar modules/functors *)
=C2=A0 ...
=C2=A0 le= t foo () : SS.t =3D
=C2=A0=C2=A0=C2=A0 SC.run SS.empty
= end

I don't really want to define the type of Make because I have to=20 constrain that SS, SM, and SC all preserve applicative identity in a=20 type constraint.=C2=A0 Then I have to do the same thing for every=20 CustomFunctor as well.=C2=A0 Worst, it's difficult to tell when things = have=20 been broken because exactly which equality is missing is completely=20 opaque in the type checking -- especially when most of the uses of these modules is just plumbing (to preserve applicative identity).
Thanks all,
Arlen

On Thu, Sep 20, 2018 at 10:29 AM Arle= n Cox <arlencox@gmail.com> = wrote:
Hi everyone,

I'm having some trouble getting some code that relies heavily o= n applicative functors to type check.=C2=A0 Does anyone know what I'm d= oing wrong with this?

module type S =3D sig
=C2= =A0 module T : Set.OrderedType
=C2=A0 module ST : module type of Set.Mak= e(T)
end

module Make(T_in : Set.OrderedType) : S (* <- ERROR *= )
=C2=A0 with module T =3D T_in
=C2=A0=C2=A0 and module ST =3D Set.Ma= ke(T_in)
=3D struct
=C2=A0 module T =3D T_in
=C2=A0 module ST =3D = Set.Make(T_in)
end

I get the following error me= ssage referencing the above point in the program.

<= div>Error: In this `with' constraint, the new definition of ST
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 does not match its original definition in= the constrained signature:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Type declarations do not match:
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type t =3D Set.Make(T_in).t=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not included in
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type t =3D Set.Make(T).t
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 File "set.mli", line 68, characters 4= -10: Expected declaration
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 File &quo= t;set.mli", line 68, characters 4-10: Actual declaration
It seems to me that since T =3D T_in, but applicative functors = should make the type of Set.Make(T) =3D Set.Make(T_in).=C2=A0 Does this not= work this way?

Note that if I change the definiti= on of S slightly, the same definition of Make now type checks:
module type S =3D sig
=C2=A0 module T : Set.OrderedType
= =C2=A0 module ST : Set.S with type elt =3D T.t
end

<= div>This solution is undesirable because I have a number of modules whose t= ypes would require an excessive number of "with module ... =3D ...&quo= t; constraints to constrain in this way.=C2=A0 Is there a better way of get= ting this to type check?

Thank you,
Arle= n


--00000000000095273305764fa547--