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 1C1A57EF38 for ; Tue, 4 Aug 2015 08:51:50 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of paurkedal@gmail.com) identity=pra; client-ip=209.85.215.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of paurkedal@gmail.com designates 209.85.215.44 as permitted sender) identity=mailfrom; client-ip=209.85.215.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; 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@mail-la0-f44.google.com) identity=helo; client-ip=209.85.215.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="postmaster@mail-la0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAQB6YMBVmyzXVdFbhFeDI64ZkyQCgTBMAQEBAQEBEgEBAQEBBgsLCSEuhCQBAQQSEQ8BDQEbHQEDDAYFGAICBRMOAgIPBQ8RAQUBIjWHdgEDEgQBpzKBLj4xiz+BbIJ5i0EKGScNV4RgAQEBAQEBAQEBAQEBAQEBARYBBQ6BFIM3hnaFCAeCaS+BFAEElHuMTgKBR4cFjSWCGDWBFxeEDm2CTAEBAQ X-IPAS-Result: A0CIAQB6YMBVmyzXVdFbhFeDI64ZkyQCgTBMAQEBAQEBEgEBAQEBBgsLCSEuhCQBAQQSEQ8BDQEbHQEDDAYFGAICBRMOAgIPBQ8RAQUBIjWHdgEDEgQBpzKBLj4xiz+BbIJ5i0EKGScNV4RgAQEBAQEBAQEBAQEBAQEBARYBBQ6BFIM3hnaFCAeCaS+BFAEElHuMTgKBR4cFjSWCGDWBFxeEDm2CTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,607,1432591200"; d="scan'208";a="141961372" Received: from mail-la0-f44.google.com ([209.85.215.44]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Aug 2015 08:51:49 +0200 Received: by labgo9 with SMTP id go9so526936lab.3 for ; Mon, 03 Aug 2015 23:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=N/zTQC4GK/cX2s27u3a7X/v1WdRZQNCGXpeFeVd8gHc=; b=wkzOim5x6Kg7qABk3t0BELDNUsBDZgIY5VSk9aedppviW7eLZJC7bj6sQoKkpreOqr 5MbUyiRYtntGPejn/zR0smu8w270x5Wei2/vdDoEneESmGcBXJ6e/VV/9LShEI/ijjpT ZXmWRdgeZAi0XxEzA7AHPjIcZKIJ3LphtKSMYYElFBQLvHIoPR7nOKEi9XVSsYennIkb ETTEJOAuf8fycqaq9tFPXrl5yAY79ael/924AgV6Zp28OEaqypUfyAVdQdAFefYcyPja VuJzUt7BP4x1v+EwBdoPEfiMHx8RjJ8T+s9PX2fg4TAXBn3oLeQyhvOWQJE4Lj31FZhB xAkg== X-Received: by 10.112.146.36 with SMTP id sz4mr1744935lbb.54.1438671108422; Mon, 03 Aug 2015 23:51:48 -0700 (PDT) Received: from dione.int.eideticdew.org ([79.142.225.158]) by smtp.gmail.com with ESMTPSA id kc4sm12499lbc.39.2015.08.03.23.51.47 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Aug 2015 23:51:47 -0700 (PDT) Date: Tue, 4 Aug 2015 08:51:34 +0200 From: Petter Urkedal To: Daniel =?utf-8?Q?B=C3=BCnzli?= Cc: Nils Becker , Caml-list Message-ID: <20150804065134.GA10576@dione.int.eideticdew.org> References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] destructive local opens On 2015-08-03, Daniel Bünzli wrote: > Le lundi, 3 août 2015 à 15:08, Nils Becker a écrit : > > It's possible that people actually want M.() to mean let open! more > > often than let open. For me I think that's the case. > > If you are in the vector case, I don't think that's the case. With Gg [1] I often had the following kind of subtly wrong code (can't remember the exact details but something similar): > > let ox = V2.((dot v ox) * ox) in > V2.(3 * ox + oy) > > The reality is that M.() is inherently dangerous, especially from an API evolution perspective where new identifiers with matching type may get introduced later leading to silent semantic changes in your code. So we should not encourage people to use M.!() as it's going to make the problem even more acute. Besides we should have that 44 warning by default so that we see the problems, but for now it's impossible to live with 44 and a Gg like library. This suggests another option. If type information is available at the point this warning is emitted, then the warning could be issued only in the case when the type of the shadowing identifier matched that of the shadowed identifier. This assumes the common case for shadowing is to redefine operators or common functions at a custom type, the use of M.() being an alternative to overloading. Loosely the warning should be emitted if the chosen identifier is not the one which would have been chosen by some sensible overloading scheme, but instead we make a simple estimate. This could still go wrong, since the type required by the context may be general than the type of both the shadowed and shadowing terms, so a better rule might be to issue the warning if both are admissible in the given context, though my guess is that's harder to implement.