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 2B3EB7EEBF for ; Tue, 4 Aug 2015 11:33: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: A0D1AAA0hsBVnAQP49RbyTwCgTFMAQEBAQEBEgEBAQEBBg0JCSEuhCQBAQQyAVYLGAklDwUoiEwBGcQxH4VvAQsgi0+FDxeDAYEUBZR7jE6BSYcFDI0Zg2SEJYM5AQEB X-IPAS-Result: A0D1AAA0hsBVnAQP49RbyTwCgTFMAQEBAQEBEgEBAQEBBg0JCSEuhCQBAQQyAVYLGAklDwUoiEwBGcQxH4VvAQsgi0+FDxeDAYEUBZR7jE6BSYcFDI0Zg2SEJYM5AQEB X-IronPort-AV: E=Sophos;i="5.15,607,1432591200"; d="scan'208";a="141977982" Received: from mout.web.de ([212.227.15.4]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2015 11:33:03 +0200 Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0LoYWI-1YuOVo3TPm-00gXUr for ; Tue, 04 Aug 2015 11:33:02 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1ZMYak-00020C-3d for caml-list@inria.fr; Tue, 04 Aug 2015 11:33:02 +0200 Date: Tue, 4 Aug 2015 11:33:02 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20150804093301.GD5689@frosties> References: <55BF6F1C.3050705@bioquant.uni-heidelberg.de> <55BF75F6.1040006@bioquant.uni-heidelberg.de> <8E1A640CE3374EB492981ADB0A2DA5C6@erratique.ch> <20150804065134.GA10576@dione.int.eideticdew.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150804065134.GA10576@dione.int.eideticdew.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:0lmap9i4f2xCm44m+VzQS1SlIW77nMRsvQmO+z10dNJ2YtnPacY niG1QjPb+glmiFlikA5pKEvMpRYxJdxjbqqnnp4wtwUAjANo5/pYXkKUhFdpPiLfL+qxn2r gLn9Xnt6hNxK8J/mDQHOdzCfTCRa+CwilPTxD9r1fGpzpEtJtNVYERBMOcklFA772MFpWz5 fEVGe1GS/MhJEUqnle9dQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:OQ57CmqxcxI=:HPdJIYot2CYURWhekftjKZ Km+TMIFt36Pdk55ksZStQyQjQizewol/1GdJhY5SmRdHUndYjCVD8PYCXvEJVf7VezrbSE0NX uGjBn1FBigwHIpjk8sNyb4pirXdworAk32zBLcLK58WQgu8a2cNGygPMEj5X5MWW9Q85bO2AJ SLu9pvQAFOIPDo8TnUV1cjbpghJenRCDIO0bK5hQCi3rIh1t3QwSkCRpLluXIbiB6qFXSzcNB m59o3w9XPXqvfQ9J5D2vcmnIrYbzpCe2oRcxXmRZxvkZ9d5TXCWF0TJRlL9m9l+MZgslWjp/V MhWQvAOSVP4HvtrPry+PVwj69EvjE1lP0nYA0UieqX3f/Z4wAOGlCgOi1U6cgYW4z4JVB9cXP CxI0s3s0cmy24tyBefgSWYGFZHC/4nEhJGKmsC1Jz9c6DK0f5agehdCJ2WiUT49Uw4Ene7gP6 V10CfxnCiFCGkVGVH9kdR7jXn2OVhj3k+vByZk6eR+4FFFQ5qDpqnvPDpBLtsgxTquihYDgTE w4RFNOF79cc0AoZmI8DZGX7V1MFXg9NAS8A0EkH6YPAG9px+0O+Idf01vrOuEl7DFs4kcxoaP dqEE3SJUZzTO9GVOlP2I+uQsIb84rIDwJOPFt+CBedZF1QnxRv1ozgH/SzD8bqeZjtOYAvSGV gZHCnf2BAw/oKBkvo4jn0lKR2l5Vf4EBwy3Xqv4Hnv6HK8A== Subject: Re: [Caml-list] destructive local opens 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. MfG Goswin