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 4B6E47EF38 for ; Thu, 6 Aug 2015 11:35:04 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.4 as permitted sender) identity=mailfrom; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; 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@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJAQDOKcNVnAQP49RbhFjFFgKBR0wBAQEBAQESAQEBAQEGDQkJIS6EIwEBAQMBJwsBSwsLGAklDwUoNIgYAQMKDMZpHysihS0BAQgCAR+LT4UQgxiBFAWVAYxVgUmHCQyNL4NkhCVtgkwBAQE X-IPAS-Result: A0BJAQDOKcNVnAQP49RbhFjFFgKBR0wBAQEBAQESAQEBAQEGDQkJIS6EIwEBAQMBJwsBSwsLGAklDwUoNIgYAQMKDMZpHysihS0BAQgCAR+LT4UQgxiBFAWVAYxVgUmHCQyNL4NkhCVtgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,622,1432591200"; d="scan'208";a="142165625" Received: from mout.web.de ([212.227.15.4]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2015 11:35:03 +0200 Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0MfqWi-1ZBH0N0j2a-00N7rx for ; Thu, 06 Aug 2015 11:35:03 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1ZNHZm-0004Xq-IV for caml-list@inria.fr; Thu, 06 Aug 2015 11:35:02 +0200 Date: Thu, 6 Aug 2015 11:35:02 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20150806093501.GD16477@frosties> References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <20150804065134.GA10576@dione.int.eideticdew.org> <20150804093301.GD5689@frosties> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:Eu8usXxgwVv+wyWL7g9hU9SfIny8XPixgI/mS3mGjhYH4Ipqqo4 T0NzhyJla3qudDzTqdS9Lk3qYWlX1ZPG+WhNJm5Wv20oI061r1uc2YInfEW7bTE/yg+5shI u4F06v4wK3K/z/6N4NEsaEwGhu1WvXzuBhZVoPIdecva7jS79SUvwbp227/hcTYmTDcEfcA yGyeJi9IovNuU5aZXjAzw== X-UI-Out-Filterresults: notjunk:1;V01:K0:K010D1zQqjQ=:Ok/lqe+9LOLmn60IG34NVo gJXb6mgJ3ZWlaRsCViyfh39jsT3idY+lvTJI0Of0UG///9pSH3ohYOxxQZqjVO4QOnJ4RUtG6 bBZHdyvktFxXsPsf6W0ggl6IpXOPgv1EP8aK5xjezOtkqA2rH/u/3ucpjAqyNauK6Q/T1cMrV 9SCr6xl+tNqzQ5WPvtBPyanta6E68oVcikSCdkiCWGQeJvtQyVhvPb46flvgxc6+7evntB0Q0 Vbe+N7gctX8YJVOUU9I05qSeSFzKuOteS0d5+aJ0CPJI0c+Mbyq7KhmHpLTInYdrCnIrS3DTu RP67YV4/vda0vWm2twldwdLMNWtbqqUwnEUb8YWe4FFGVRYFJxQk9HNT9tjRjQN8aprPRu6nD lH7mttKJYredyjEYYrazFJ4T0aiDjzPSzEuxa3ywG21AVi3aSLjkbc5zQo25HARUyxiPbSnTx 6+90yEMJ4Jo92aky4hHi91Q+Tbmo8TWnEeiqiiS3ISx1Hu9ShtLiHznS814JGrZYp9s4wXoWr AT+dBWXVBMJ4miowq9iYdZFDkSprYZiSpAv0PnmdkUGNn3Vura2phHtH9fXcp0N9wIy7F4PeA +OLkJEKOJW+KuO6np3EBSSG3uREM5TNnDqtjY3iB7a+Gs6wpomv9iKxjqP8a7O7k/l2cfGc6X kwKy0w1lYfn9fE4QGHpKJ9sNPRME+3470t7OcHOLI66m7KQ== Subject: Re: [Caml-list] destructive local opens On Wed, Aug 05, 2015 at 08:40:21AM +0200, Petter A. Urkedal wrote: > 2015-08-04 11:33 GMT+02:00 Goswin von Brederlow : > > On Tue, Aug 04, 2015 at 08:51:34AM +0200, Petter Urkedal wrote: > >> 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. > > > > I like the idea but how feasable is it? Most of the time I figure the > > type being infered from the operator being used. The use of M.(*) > > makes it the custom type while simple (*) would make it int. The type > > system would have to track the ambiguity until some other use of the > > arguments or result decide the proper type. And if it doesn't resolve > > then emit the warning. > > Yes, it's probably not that easy to implement. Not familiar with the > code base. At least it requires postponing the warning till type > information is available, and maybe cluttering the parse tree with > sub-nodes containing the types and locations of shadowed identifiers. > The types at the point the check is made will have been analysed under > the assumption that the right resolution was made. Ahh, I was thinking wrong. In M.(x + y) the type of x and y would usualy be unknown at first. The type of x and y don't matter though. Only the existance and type of M.(+) should be considered and would usualy be fixed by the module. Worst case you have to add type annotations or a signature to the module to make its API properly typed. Then when the compiler hits '+' it sees the M.(+). It then has to keep looking for the previous (+) and compare the two types. It could then not simply compare them but check if they can be unified one direction or the other. So overloading int -> int -> int with 'a -> 'a -> 'a would give the warning while int -> int -> int with Vec.t -> Vec.t -> Vec.t would not. In case of 'a adding type annotations to the operator would fix the warning. > I originally assumed we had closed types, only type variables stemming > from let-polymorphism. That may be the case for M-bound identifiers > in M.(...), but the context may contain local identifiers or > file-level identifiers with unresolved existentials. Nevertheless, I > think the common case when we don't want to emit a warning is when > M.(...) shadows a global binding whose type was already fixed. MfG Goswin