From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 B7E6E824CF for ; Thu, 29 Nov 2018 09:53:40 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yrg@irif.fr; spf=Pass smtp.mailfrom=yrg@irif.fr; spf=None smtp.helo=postmaster@korolev.univ-paris7.fr Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yrg@irif.fr) identity=pra; client-ip=194.254.61.138; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yrg@irif.fr"; x-sender="yrg@irif.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yrg@irif.fr designates 194.254.61.138 as permitted sender) identity=mailfrom; client-ip=194.254.61.138; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yrg@irif.fr"; x-sender="yrg@irif.fr"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@korolev.univ-paris7.fr) identity=helo; client-ip=194.254.61.138; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yrg@irif.fr"; x-sender="postmaster@korolev.univ-paris7.fr"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AfJ9bhhxis8PaIKPXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?1O8QIJqq85mqBkHD//Il1AaPAd2Lraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze+/94HQbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDtU7s6RSqt4LtqSB/wiS?= =?us-ascii?q?cIKTg58H3MisdtiK5XuQ+tqwBjz4LRZoyeKfhwcb7Hfd4CSmVPXshfWS9cDI2i?= =?us-ascii?q?c4QCFPAOMfpCooTnu1cCsRmzCA+xD+3v0D9IgXr20LU43Os7FwHG2hErEc4Ut3?= =?us-ascii?q?TbrdX1L74eX+G0zKbSyzXMdehW0ir65YnIaBAhruqBXbNqccrQx0kjDQ3Fjk+J?= =?us-ascii?q?pIHjIjib1fwNvnCG4+dkWu+jkXArpgF+rzS1x8ogl5PFip8bx13H7Sl13po5KN?= =?us-ascii?q?miREN4YdOoCoVcuzyGO4dsX88vQWVltSAnwbMco5G7ZjIFyJE/yh7fdfOHd4+I?= =?us-ascii?q?7wrgVOaWOzd4g3Zld6yhhxqo7EigzOz8Vtet3FZStCVFiNjMtmsP2hDJ5MiHUO?= =?us-ascii?q?Nx/kan2TmRywDe8vxILEQ7mKbBNZIswrE9moASvEjeBCP6hUv7gayOekUh4Oeo?= =?us-ascii?q?6uDnYrv8pp+bMo95kgH/Mr4hmsGkAOQ4KAkOX2aB9eSyzr3v5Vf5T6lSjv0qjq?= =?us-ascii?q?nZt4jXKtgBqa68Bw9Zy4Ij6xekDze6y9kYhnkGLFddeB2dlYTpOlfOIOr5Dfil?= =?us-ascii?q?mVisni1rlLj6OejGCZzIKjDmmbblfLByo2pd0xZ7mdtW4pYRDrAaPNryXFXwvZ?= =?us-ascii?q?rWFElqHRazxrPWAdN7nrmfVmOUR4CYOaXbqhfc9/ggC+iWZYFTtiyreKtt3OLn?= =?us-ascii?q?kXJswQxVRqKux5ZCLSngRq03cXXcWmLlh5I6KUlPuwM/SOLwj1jTAz9JZnj0Ub?= =?us-ascii?q?huv2hnWrLjNp/KQ8WWuJLExD2yT89XfGFITF6WQy+xKte0HswUYSfXGfdP1zwJ?= =?us-ascii?q?Ub/7F90i0gupsALkjadhL/SR4iQCtIm8ktZvtbXe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcCADcqP9bh4o9/sJlHgEGBwaBZQKDa?= =?us-ascii?q?oQgcC2HWospghyCdwGGf409E4FmDSsBh3EaBwEENgQMAQMBAQIBAQEBARMBAQE?= =?us-ascii?q?KCwkIKS+CNiQBgwtvBgc3AiQSAQUBFgyDNIICBIpPjGmDHjyLDYEviR+BDowWF?= =?us-ascii?q?4F/iGwcgyCCVwKPJJB7CYEMkCYYkRqYOw8hgQU6DoFlTScRbAaCNoI0jic/AYE?= =?us-ascii?q?2AQGNMgEB?= X-IPAS-Result: =?us-ascii?q?A0AcCADcqP9bh4o9/sJlHgEGBwaBZQKDaoQgcC2HWospghy?= =?us-ascii?q?CdwGGf409E4FmDSsBh3EaBwEENgQMAQMBAQIBAQEBARMBAQEKCwkIKS+CNiQBg?= =?us-ascii?q?wtvBgc3AiQSAQUBFgyDNIICBIpPjGmDHjyLDYEviR+BDowWF4F/iGwcgyCCVwK?= =?us-ascii?q?PJJB7CYEMkCYYkRqYOw8hgQU6DoFlTScRbAaCNoI0jic/AYE2AQGNMgEB?= X-IronPort-AV: E=Sophos;i="5.56,294,1539640800"; d="scan'208,217";a="287227736" Received: from korolev.univ-paris7.fr ([194.254.61.138]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2018 09:53:08 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wAT8r2Es013864 for ; Thu, 29 Nov 2018 09:53:02 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9505733FAA for ; Thu, 29 Nov 2018 09:53:08 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ppAlZQXF5D58 for ; Thu, 29 Nov 2018 09:53:06 +0100 (CET) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (Authenticated sender: yrg) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4060033FA0 for ; Thu, 29 Nov 2018 09:53:06 +0100 (CET) Received: by mail-pf1-f179.google.com with SMTP id b7so677425pfi.8 for ; Thu, 29 Nov 2018 00:53:06 -0800 (PST) X-Gm-Message-State: AA+aEWbz+euTg244tfldN8ahCUhOH7wsrRGLtgQj7Jlkvwnfr4aG85YT nPn+jFXQ/x3Zy79C+GaL2FFzt3O7KU+HTsRZZRc= X-Google-Smtp-Source: AFSGD/Vk6SlsyKxYGAIGGOTysvcM8df9eEJpiAOw3B0qu/AI1lFyD7uVURLfbHHt4qEMFfT/jypL3nPzR9nmhLb86rM= X-Received: by 2002:a62:931a:: with SMTP id b26mr592324pfe.65.1543481584916; Thu, 29 Nov 2018 00:53:04 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?WWFubiBSw6lnaXMtR2lhbmFz?= Date: Thu, 29 Nov 2018 09:52:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary="00000000000096219c057bc9cfbd" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 29 Nov 2018 09:53:02 +0100 (CET) X-Miltered: at korolev with ID 5BFFA8EE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BFFA8EE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5BFFA8EE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [Caml-list] include two module implementations sharing the same type definitions --00000000000096219c057bc9cfbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear OCaml module hackers, the recently polished "substitution inside type signature" (described in Sec 8.11 in the manual) is a real improvement to modularize module signature developments. Yet, it seems to me that "include" at the level of module implementations is preventing us to unleash the full composability power of "include" at the level of signature. Consider the following example: `` module type A =3D sig type t end module type B =3D sig type t end type u =3D U module AI : A with type t =3D u =3D struct type t =3D u end module BI : B with type t =3D u =3D struct type t =3D u end module ABI : sig include A include B with type t :=3D t end =3D struct include AI include BI (* This include unfortunately triggers: Error: Multiple definition of the type name t. Names must be unique in a given structure or signature. *) end `` I have two questions: Would it make sense to allow module implementation inclusion to introduce multiple definitions of a given type name as long as these definitions are equivalent? Is there an idiom to work around this (apparent) limitation? Cheers, --=20 Yann R=C3=A9gis-Gianas --00000000000096219c057bc9cfbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear OCaml module hackers,

the recently= polished "substitution inside type signature" (described in Sec = 8.11 in the manual) is a real improvement to modularize module signature de= velopments.=C2=A0

Yet, it seems to me that "i= nclude" at the level of module implementations is preventing us to unl= eash the full composability power of "include" at the level of si= gnature. Consider the following example:

``
<= div>
module type A =3D sig type t end

module t= ype B =3D sig type t end

type u =3D U
module AI : A with type t =3D u =3D struct
=C2=A0 ty= pe t =3D u
end

module BI : B with type t= =3D u =3D struct
=C2=A0 type t =3D u
end
module ABI : sig
=C2=A0 include A
=C2=A0 in= clude B with type t :=3D t
end =3D struct
=C2=A0 includ= e AI
=C2=A0 include BI (* This include unfortunately triggers:

Error: Multiple definition of the type name t.<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Names must be unique in a given struct= ure or signature.

=C2=A0 *)
end
``

I have two questions:
<= br>
Would it make sense to allow module implementation inclusion = to introduce multiple definitions of a given type name as long as these def= initions are equivalent?

Is there an idiom to work= around this (apparent) limitation?

Cheers,
<= /div>--
Yann R=C3=A9gis-Gianas

=
--00000000000096219c057bc9cfbd--