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 960407EEBF for ; Mon, 17 Aug 2015 16:27:32 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.172 as permitted sender) identity=mailfrom; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-ig0-f172.google.com) identity=helo; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfAgAC79FVm6zVVdFdg29pBoMeqhWEbY1FhXkCgScHTAEBAQEBARIBAQEBAQYLCwkhLoQjAQEBAwESEQQZARsSCwEDAQsGBQsNAgIJHQICIgERAQUBChIGExIQh3YBAwoIDa1FgS8+MYtAgWyCeYpKChknAwpXhQABAQEBAQUBAQEBGAEFDoEUijCFCQeCaYFDBYVsDI8lhQSHaIFKRoZ/jTGCGxIjgRcXhA48MwGCSwEBAQ X-IPAS-Result: A0BfAgAC79FVm6zVVdFdg29pBoMeqhWEbY1FhXkCgScHTAEBAQEBARIBAQEBAQYLCwkhLoQjAQEBAwESEQQZARsSCwEDAQsGBQsNAgIJHQICIgERAQUBChIGExIQh3YBAwoIDa1FgS8+MYtAgWyCeYpKChknAwpXhQABAQEBAQUBAQEBGAEFDoEUijCFCQeCaYFDBYVsDI8lhQSHaIFKRoZ/jTGCGxIjgRcXhA48MwGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,695,1432591200"; d="scan'208";a="142978572" Received: from mail-ig0-f172.google.com ([209.85.213.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Aug 2015 16:27:02 +0200 Received: by igfj19 with SMTP id j19so58522465igf.0 for ; Mon, 17 Aug 2015 07:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=risHYyXNvBj/p+dpopsxyN6fcdGlOftj/KPkDA0/jic=; b=hc9nan/LZrXzXuwc6So/FxEhnlsswsVDYaSwPx1YvFJKcDuoI7+oBe7zs22R8G9PKD flMTi52XRV8mJf6sHscJM4+hMDGeqIqwM1yUPRb8PvPNnKNinMZThEHu6CyKsP2CDhmY Z9tA0NQX/8t0v8QMuUP97rpeBmvU4bj641ZqXiDtRCRjGCmgXSc1Q70SzGrpMgVdWJCl FPvwBTVoWPxJJeBwN2nXGqSsGC6kn51CWCU/weQCkPPK9bE1P7wvqN6Bil1hHKbZYFLd 1r7l2sycsL0UvRELpXPJUq4cnD6Td/XO8r2VccZLcLs3AxAafD8e8ztY3OPA9ipSG/1t x6Lg== X-Received: by 10.50.138.76 with SMTP id qo12mr17694311igb.38.1439821621422; Mon, 17 Aug 2015 07:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Mon, 17 Aug 2015 07:26:22 -0700 (PDT) In-Reply-To: <55D1B49C.2040309@bioquant.uni-heidelberg.de> References: <55D1B49C.2040309@bioquant.uni-heidelberg.de> From: Gabriel Scherer Date: Mon, 17 Aug 2015 16:26:22 +0200 Message-ID: To: Nils Becker Cc: caml users Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] destructive local opens > 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. Indeed, I don't think anyone planned to have (let open{,!} M in ...) behave differently from M.{!,}(...). In fact I don't think there is any distinction between those two constructions at the level of typing derivations (except maybe as on-the-side annotation for pretty-printing), so it is natural to handle them in exactly the same way. I proposed an implementation of the distinction between operators and alphanumeric identifiers in Shadow warnings: 44 refined into 52,53 for alphanumeric identifiers and symbolic operators https://github.com/ocaml/ocaml/pull/232 and this is orthogonal to the question of whether to add M.!(...), for which a patch was proposed by Gabriel Radanne in Short syntax for overriding local open https://github.com/ocaml/ocaml/pull/218 I am of the opinion that, whether we decide to introduce M.!(...) or not (this looks like a good idea for consistency), both (let open!) and M.!(...) are dangerous constructions that should be avoided whenever possible, and that we could and should drastically reduce the number of situations where the user is encouraged to use them. (Another idea I had was to write !, which would have the same semantics as , except that it claims that the identifiers bound in shadow identifiers in scope. I find this syntax cute, but the symmetry with ((!) : 'a ref -> 'a) is troubling in a bad way.) On Mon, Aug 17, 2015 at 12:17 PM, Nils Becker wrote: > 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. > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs