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 2C0727EEBF for ; Mon, 17 Aug 2015 12:12:19 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nils.becker@bioquant.uni-heidelberg.de) identity=pra; client-ip=129.206.210.211; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="nils.becker@bioquant.uni-heidelberg.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nils.becker@bioquant.uni-heidelberg.de) identity=mailfrom; client-ip=129.206.210.211; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="nils.becker@bioquant.uni-heidelberg.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay2.uni-heidelberg.de) identity=helo; client-ip=129.206.210.211; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="postmaster@relay2.uni-heidelberg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeAQACs9FVnNPSzoFdh3zCPYEuTAEBAQEBARIBAQEBAQgLCQkhLoQlBCQPAUUGFhoCBRYLAgsDAgECAVgIAQGIIgiqA49jlXeBIoowhFZRglKBQwWSEYMMjjaHICWNMYNngXAMAYIogzsBAQE X-IPAS-Result: A0CeAQACs9FVnNPSzoFdh3zCPYEuTAEBAQEBARIBAQEBAQgLCQkhLoQlBCQPAUUGFhoCBRYLAgsDAgECAVgIAQGIIgiqA49jlXeBIoowhFZRglKBQwWSEYMMjjaHICWNMYNngXAMAYIogzsBAQE X-IronPort-AV: E=Sophos;i="5.15,694,1432591200"; d="scan'208";a="142956323" Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2015 12:12:18 +0200 Received: from ix.urz.uni-heidelberg.de (cyrus-portal01.urz.uni-heidelberg.de [129.206.100.176]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t7HACHKA025799 for ; Mon, 17 Aug 2015 12:12:17 +0200 Received: from extmail.urz.uni-heidelberg.de (extmail.urz.uni-heidelberg.de [129.206.100.140]) by ix.urz.uni-heidelberg.de (Postfix) with ESMTPS id 1ABE321B6343 for ; Mon, 17 Aug 2015 12:12:17 +0200 (CEST) Received: from bqdyn253_067.bioquant.uni-heidelberg.de (bqdyn253_067.bioquant.uni-heidelberg.de [129.206.253.147]) (authenticated bits=0) by extmail.urz.uni-heidelberg.de (8.13.4/8.13.1) with ESMTP id t7HAC4iZ012276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 17 Aug 2015 12:12:21 +0200 To: caml-list@inria.fr From: Nils Becker X-Enigmail-Draft-Status: N1110 Message-ID: <55D1B49C.2040309@bioquant.uni-heidelberg.de> Date: Mon, 17 Aug 2015 12:17:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Validation-by: nils.becker@bioquant.uni-heidelberg.de Subject: Re: [Caml-list] destructive local opens Sorry for the late comment. The mentioned bug: > let ox = V2.((dot v ox) * ox) in > V2.(3 * ox + oy) because V2 also has V2.ox sure is nasty. But the same would happen with a local 'let open V2'. let ox = let open V2 in (dot v ox) * ox in V2.(3 * ox + oy) For ease of reasoning I think it may be a good idea to make M.(...) and M.!(...) behave in exactly the same way as let open and let open! respectively, including error messages. This would probably forbid distinguishing between infix operators and the rest. (Admittedly, in the latter example one would be tempted to combine the local opens here which would make things clearer) > The reality is that M.() is inherently dangerous, When one uses a (destructive) local open one trades the possibility of ambiguity for conciseness. In a few cases the conciseness is really, really important, so that this trade-off is worth it. (I'm thinking about math.) The existence of let open! in the language says that there is some consensus that ambiguity is sometimes acceptable. > 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. It's not that bad. Destructive opens mean one has to know the shadowing module's signature. Only the values exported in the signature actually shadow anything (I just tried it out) so one does _not_ need to know the module source! Right now, one cannot really use M.(...) to shadow without deactivating warning 44. This is not ideal. With the syntax M.!(...) one would be forced to declare shadowing intent and 44 could be switched on. Then let ox = V2.!((dot v ox) * ox) in V2.!(3 * ox + oy) would still let the same bug happen but at least one was forced to write an exclamation mark which should give a feeling of "be careful about shadowing here!". Would this not be enough? n.