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 C08F87EEBF for ; Mon, 3 Aug 2015 18:13:15 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=pra; client-ip=217.70.183.196; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of octa@polychoron.fr) identity=mailfrom; client-ip=217.70.183.196; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="octa@polychoron.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay4-d.mail.gandi.net) identity=helo; client-ip=217.70.183.196; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="octa@polychoron.fr"; x-sender="postmaster@relay4-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASAgCzkr9Vh8S3RtlbGQEBAYRBgx2kZIEtAQEGmEaCVgKBL0wBAQEBAQESAQEBCA0JByMuhCQBAQECARIRBBFBBQsLGgIFIQICDwJGBg0IAQEeiAQGBgOqL4oklWUBAQgCAR+BIoR9hTCEVTMHgmmBQwWUeYE/jFSHEiKMaYNiAheEDoI1gQQBAQE X-IPAS-Result: A0ASAgCzkr9Vh8S3RtlbGQEBAYRBgx2kZIEtAQEGmEaCVgKBL0wBAQEBAQESAQEBCA0JByMuhCQBAQECARIRBBFBBQsLGgIFIQICDwJGBg0IAQEeiAQGBgOqL4oklWUBAQgCAR+BIoR9hTCEVTMHgmmBQwWUeYE/jFSHEiKMaYNiAheEDoI1gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,602,1432591200"; d="scan'208";a="141924242" Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Aug 2015 18:13:15 +0200 Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C5F99172085; Mon, 3 Aug 2015 18:13:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id E_kiJlYtfq14; Mon, 3 Aug 2015 18:13:13 +0200 (CEST) X-Originating-IP: 105.250.50.187 Received: from [192.168.42.219] (vc-cpt-105-250-50-187.umts.vodacom.co.za [105.250.50.187]) (Authenticated sender: octa@polychoron.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6F407172097; Mon, 3 Aug 2015 18:13:11 +0200 (CEST) To: =?UTF-8?Q?Daniel_B=c3=bcnzli?= References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <55BF8451.3060408@polychoron.fr> Cc: Gabriel Scherer , Nils Becker , Caml-list From: octachron Message-ID: <55BF9314.70904@polychoron.fr> Date: Mon, 3 Aug 2015 18:13:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] destructive local opens 08/03/15 17:22, Daniel B=C3=BCnzli wrote : > Le lundi, 3 ao=C3=BBt 2015 =C3=A0 16:10, octachron a =C3=A9crit : >> Splitting 44 between alphanumeric and other identifiers is a nice >> default but it sounds a little arbitrary. > I don't think it's arbitrary, it matches the use case for the M.() notati= on. >=20=20=20=20 I agree that it matches many use cases of the M.(); but not all of them.=20 And, I am not sure that the splitting should be done on the operators/alphanumeric identifiers=20 criterion: If I define an exotic operator, for instance "@->", it would be very sensible to emit a=20 warning if this exotic operator is shadowed. Similarly, in a Triple module defining a "fst" function is=20 very natural. It could be nice to be able to disactivate the warning on the shadowing of Pervasive 's "fst".=20= =20 For these reasons, I think that it is could be useful to let the choice to library authors. >> Like this, library writers could annotate identifiers that are intended >> to shadow predefined identifiers without any limitations, and cautious >> users could activate 53 to protect themselves from unexpected >> identifiers shadowing? > Somehow I prefer to have a well defined broad rule, rather than letting l= ibrary authors micro manage that. A broad rule is clearly easier to remember, so it is a question of=20 compromise. > The benefit is that I can understand what is happening by only looking at= the expression I'm reading. With your proposal I also need to go read the = library source to understand what is happening. > I think that it is partially true. For instance, with a vector library,=20 "*" is always quite ambiguous: Is this the original scalar=20 multiplication? The vector product? The tensor product? The external=20 product? The Clifford algebra product? These ambiguities already needs=20 to be resolved in the documentation; where the eventual [@shadow]=20 annotations also ought to be mentionned. Regards, octachron.