From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 399677FE44 for ; Wed, 6 Jul 2016 14:29:13 +0200 (CEST) IronPort-PHdr: 9a23:CrYR7hHNJgwIjnPA4Cv4E51GYnF86YWxBRYc798ds5kLTJ75r8uwAkXT6L1XgUPTWs2DsrQf2rKQ6f6rAjxIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWD14Ltiavpq9X6WEZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1e1wyserAvBzHBS6G538dVGpethtTH0CR5xj/WtL1szDmnut7wiiTe8PsG+MaQzOnuoVsQxLsmSEwDL8j932f3u53h69fsRTnnBFlxJL8fYeUKr90ZqjZcMkfQmxdGMhLAX8SSrigZpcCWrJSdd1TqJPw8h5X9UOz Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=Jocelyn.Serot@univ-bpclermont.fr; spf=None smtp.mailfrom=Jocelyn.Serot@univ-bpclermont.fr; spf=None smtp.helo=postmaster@mta02.udamail.fr Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Jocelyn.Serot@univ-bpclermont.fr) identity=pra; client-ip=193.49.117.21; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Jocelyn.Serot@univ-bpclermont.fr"; x-sender="Jocelyn.Serot@univ-bpclermont.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Jocelyn.Serot@univ-bpclermont.fr) identity=mailfrom; client-ip=193.49.117.21; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Jocelyn.Serot@univ-bpclermont.fr"; x-sender="Jocelyn.Serot@univ-bpclermont.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mta02.udamail.fr) identity=helo; client-ip=193.49.117.21; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Jocelyn.Serot@univ-bpclermont.fr"; x-sender="postmaster@mta02.udamail.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANAgB1+HxXhxV1McFdhAeBCa0hhwqGfYYYAoEsOxEBAQEBAQEBAREBAQEKCwkJIS+CMoIaAQEEAX4LCxguITYGE4gWAw8MAbdODYQxAQEIAQEBAQEBASCIHwiCTYJDgX2DLIIvAQSOBIpbNIc6hH2LW4VfiBeHcQI0gjmBWWyIcgEBAQ X-IPAS-Result: A0ANAgB1+HxXhxV1McFdhAeBCa0hhwqGfYYYAoEsOxEBAQEBAQEBAREBAQEKCwkJIS+CMoIaAQEEAX4LCxguITYGE4gWAw8MAbdODYQxAQEIAQEBAQEBASCIHwiCTYJDgX2DLIIvAQSOBIpbNIc6hH2LW4VfiBeHcQI0gjmBWWyIcgEBAQ X-IronPort-AV: E=Sophos;i="5.28,318,1464645600"; d="scan'208";a="184046046" Received: from mta02.udamail.fr ([193.49.117.21]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 14:29:12 +0200 Received: from mta02.udamail.fr (localhost.localdomain [127.0.0.1]) by mta02.udamail.fr (Postfix) with ESMTPS id 3E2F21601E0 for ; Wed, 6 Jul 2016 14:29:12 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.udamail.fr (Postfix) with ESMTP id 305491601E4 for ; Wed, 6 Jul 2016 14:29:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at mta02.udamail.fr Received: from mta02.udamail.fr ([127.0.0.1]) by localhost (mta02.udamail.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7eNgv8iRVIYl for ; Wed, 6 Jul 2016 14:29:12 +0200 (CEST) Received: from proxy01.udamail.fr (proxy01.udamail.fr [193.49.117.18]) by mta02.udamail.fr (Postfix) with ESMTPS id 153DE1601E0 for ; Wed, 6 Jul 2016 14:29:12 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy01.udamail.fr (Postfix) with ESMTP id 1205115E04C for ; Wed, 6 Jul 2016 14:29:12 +0200 (CEST) Received: from proxy01.udamail.fr ([127.0.0.1]) by localhost (proxy01.udamail.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id T5qc4TFChB44 for ; Wed, 6 Jul 2016 14:29:11 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy01.udamail.fr (Postfix) with ESMTP id BF04115E04D for ; Wed, 6 Jul 2016 14:29:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at proxy01.udamail.fr Received: from proxy01.udamail.fr ([127.0.0.1]) by localhost (proxy01.udamail.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TaUSFo4VUodp for ; Wed, 6 Jul 2016 14:29:11 +0200 (CEST) Received: from [192.168.0.42] (lav63-2-88-164-92-250.fbx.proxad.net [88.164.92.250]) by proxy01.udamail.fr (Postfix) with ESMTPSA id 80B4415E04C for ; Wed, 6 Jul 2016 14:29:11 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?windows-1252?Q?Jocelyn_S=E9rot?= In-Reply-To: <20160706101527.GA26606@dione.int.eideticdew.org> Date: Wed, 6 Jul 2016 14:29:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CDB6A40-3523-480F-8415-41ABFEA4A52C@univ-bpclermont.fr> References: <64440D5D-1FC8-4C53-9520-D9D3D21F8FE5@univ-bpclermont.fr> <44623127-96C5-43FB-828D-0F42DCCBA36B@univ-bpclermont.fr> <20160706101527.GA26606@dione.int.eideticdew.org> To: OCaml Mailing List X-Mailer: Apple Mail (2.1878.6) Subject: Re: [Caml-list] Q: functors and "has a" inheritance Thanks for the explanations, Gerd and Petter. At least i now have a name for the wall i=92m bumping into ;) Gerd, i can=92t figure out how your proposed workaround can solve the probl= em : if P is an argument of the Product functor, it has to be built before = applying it, hasn't it ? So either we are back to the initial problem or we= have to require that the end user manually builds it ? Am i missing sth ? Incidentelly, i tried another workaround : instead of augmenting the [Myset= ] module for getting the [MysetA] module, i tried the other way : first def= ine a SetA module with attributes attached to elements and then define a = =AB normal =BB Set module by =AB hiding =BB some operations and redefining = some others. Seems i=92m stumbling on the same problem.. :( Could it be the= case that functors just cannot support the reuse mechanism i=92m seeking f= or ?? Jocelyn Le 6 juil. 2016 =E0 12:15, Petter Urkedal a =E9crit : > On 2016-07-06, Jocelyn S=E9rot wrote: >> Hi Nicolas, >>=20 >> Thanks fro your answer. >> If i understand correctly, you mean that if i write, say : >>=20 >> module type S =3D sig type t val zero: t end >> module type T =3D sig type t val zero: t end >> module Make (X : S) =3D (struct type t =3D X.t * X.t let zero =3D X.zero= , X.zero end : T) >> module M1 =3D Make (struct type t =3D int let zero =3D 0 end) >> module M2 =3D Make (struct type t =3D int let zero =3D 0 end) >>=20 >> then the compiler will never be able to deduce that M1.t and M2.t are in= deed compatible. Am i right ? >=20 > Gerd nicely explained how, so I'm just add a note about why: >=20 > 1. If the module contained a function rather than a plain constant, it > would be undecidable in general whether the two structures were > equal. >=20 > 2. Even if we could (or adopted syntactic equality as an approximation), > it would break abstraction: Structures imported from or depending on > external libraries could be coincidentally equal at some point and > different after an upgrade. >=20 > So, we would be left with a rather ad-hoc rule about how to compare > structures. The nominal approach taken by OCaml is consistent even if a > bit conservative. Note that module paths may include functor > applications.