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 CC6D07EEBF for ; Mon, 3 Aug 2015 19:18:38 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of hendrik@topoi.pooq.com) identity=pra; client-ip=69.165.131.134; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hendrik@topoi.pooq.com"; x-sender="hendrik@topoi.pooq.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of hendrik@topoi.pooq.com) identity=mailfrom; client-ip=69.165.131.134; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hendrik@topoi.pooq.com"; x-sender="hendrik@topoi.pooq.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@april.topoi.pooq.com) identity=helo; client-ip=69.165.131.134; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="hendrik@topoi.pooq.com"; x-sender="postmaster@april.topoi.pooq.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZCADYob9V/4aDpUVbGQEBAYNSRSS+WIYBAoF9AQEBAQEBgQuEJAEBBDIBVgsYCSUPBRiIcspkAQEIAiCLT4UPF4MBgRQFlHmHGoUwAk94hzSMaYNkJoQZIjGCTAEBAQ X-IPAS-Result: A0BZCADYob9V/4aDpUVbGQEBAYNSRSS+WIYBAoF9AQEBAQEBgQuEJAEBBDIBVgsYCSUPBRiIcspkAQEIAiCLT4UPF4MBgRQFlHmHGoUwAk94hzSMaYNkJoQZIjGCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,602,1432591200"; d="scan'208";a="141928611" Received: from topoi.pooq.com (HELO april.topoi.pooq.com) ([69.165.131.134]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Aug 2015 19:18:36 +0200 Received: by april.topoi.pooq.com (Postfix, from userid 1001) id F00D31A0676; Mon, 3 Aug 2015 13:18:38 -0400 (EDT) Date: Mon, 3 Aug 2015 13:18:38 -0400 From: Hendrik Boom To: caml-list@inria.fr Message-ID: <20150803171838.GB28796@topoi.pooq.com> References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <55BF8451.3060408@polychoron.fr> <55BF9314.70904@polychoron.fr> <2C582E7B7CD34029998882AA66299107@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2C582E7B7CD34029998882AA66299107@erratique.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] destructive local opens On Mon, Aug 03, 2015 at 05:51:24PM +0100, Daniel Bünzli wrote: > Le lundi, 3 août 2015 à 17:13, octachron a écrit : > > > 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, > > "*" is always quite ambiguous: Is this the original scalar > > multiplication? The vector product? The tensor product? The external > > product? The Clifford algebra product? These ambiguities already needs > > 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 context and, if your operator are few (which they > should be), is learnable in practice. > > 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 identifiers are much more widespread than > operators, we get a much more ambiguous language. It is important that simple deductions enable the reader to understand what a program means. With a statically checking compiler (what other kind is really useful) I rely on the absence of error messages when I perform these simple deductions. Therefore I prefer to either have an explicit error message or an explicit disambiguation. -- hendrik