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 ECE627EEBF for ; Mon, 3 Aug 2015 18:52:53 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DgAAD/m79Vm0pWN0pbGQEBAYNSaYMjuzWGAQKBfQEBAQEBARIBAQEBAQgJCwkhLoQkAQEBAyNWEAsaAiYCAkcQBhuIJgS0X5VsAQEIAgEfgSKKLYRVMweCaS+BFAWUeY4ThwMPIoxpg2SEJG6CTAEBAQ X-IPAS-Result: A0DgAAD/m79Vm0pWN0pbGQEBAYNSaYMjuzWGAQKBfQEBAQEBARIBAQEBAQgJCwkhLoQkAQEBAyNWEAsaAiYCAkcQBhuIJgS0X5VsAQEIAgEfgSKKLYRVMweCaS+BFAWUeY4ThwMPIoxpg2SEJG6CTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,602,1432591200"; d="scan'208";a="141926885" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Aug 2015 18:52:52 +0200 Received: from [192.168.2.3] (cpc16-cmbg14-2-0-cust300.5-4.cable.virginm.net [86.6.157.45]) by smtp.webfaction.com (Postfix) with ESMTP id 4C599211D8FF; Mon, 3 Aug 2015 16:51:27 +0000 (UTC) Date: Mon, 3 Aug 2015 17:51:24 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: octachron Cc: Gabriel Scherer , Nils Becker , Caml-list Message-ID: <2C582E7B7CD34029998882AA66299107@erratique.ch> In-Reply-To: <55BF9314.70904@polychoron.fr> References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <55BF8451.3060408@polychoron.fr> <55BF9314.70904@polychoron.fr> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] destructive local opens Le lundi, 3 ao=C3=BBt 2015 =C3=A0 17:13, octachron a =C3=A9crit : > > 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 th= e library source to understand what is happening. >=20=20 > I think that it is partially true. For instance, with a vector library,= =20=20 > "*" is always quite ambiguous: Is this the original scalar=20=20 > multiplication? The vector product? The tensor product? The external=20=20 > product? The Clifford algebra product? These ambiguities already needs=20= =20 > to be resolved in the documentation; Note that what you raise here is a different issue it's not about knowing *= if* the operator is the one from M.() or the one in scope, but which one is= implemented. Very often this can be disambiguised by the surrounding conte= xt and, if your operator are few (which they should be), is learnable in pr= actice. With the operator warning splitting rule. The inferences are very simple: 1. Given a M.( * ) without warning the * may be the one of M or the one in = scope. Ambiguous, can't be resolved locally. 2. Given a M.( id ) without warning, if [id] is in scope I *know* this [id]= is being used. If it's not I know M.id is being used. No ambiguity, can be= resolved locally. If you allow each identifier in a module to sport an @shadow annotation you= lose 2. which I find a very valuable property. Without it, given that ide= ntifiers are much more widespread than operators, we get a much more ambigu= ous language. Best, Daniel