From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nils.becker@bioquant.uni-heidelberg.de>
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 CEB857EEBF
	for <caml-list@sympa.inria.fr>; Mon,  3 Aug 2015 15:37:54 +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.100.212;
  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.100.212;
  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@relay.uni-heidelberg.de) identity=helo;
  client-ip=129.206.100.212;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="nils.becker@bioquant.uni-heidelberg.de";
  x-sender="postmaster@relay.uni-heidelberg.de";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AAAVbr9VnNRkzoFbGQEBh1/CYEwBAQEBAQESAQEBAQEICwkJIS6ETQ8BRTYCBRYLAgsDAgECAT8ZCAEBiCqkfI9hlguBIo9TglKBQwWUeZUikHKBcAELAYIogzkBAQE
X-IPAS-Result: A0D1AAAVbr9VnNRkzoFbGQEBh1/CYEwBAQEBAQESAQEBAQEICwkJIS6ETQ8BRTYCBRYLAgsDAgECAT8ZCAEBiCqkfI9hlguBIo9TglKBQwWUeZUikHKBcAELAYIogzkBAQE
X-IronPort-AV: E=Sophos;i="5.15,601,1432591200"; 
   d="scan'208";a="141910193"
Received: from relay.uni-heidelberg.de ([129.206.100.212])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2015 15:37:50 +0200
Received: from ix.urz.uni-heidelberg.de (cyrus-portal01.urz.uni-heidelberg.de [129.206.100.176])
	by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t73DbmXs008505
	for <caml-list@inria.fr>; Mon, 3 Aug 2015 15:37:49 +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 E48BB2185032
	for <caml-list@inria.fr>; Mon,  3 Aug 2015 15:37:48 +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 t73Dbn57005990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <caml-list@inria.fr>; Mon, 3 Aug 2015 15:37:50 +0200
To: caml-list@inria.fr
From: Nils Becker <nils.becker@bioquant.uni-heidelberg.de>
X-Enigmail-Draft-Status: N1110
Message-ID: <55BF6F1C.3050705@bioquant.uni-heidelberg.de>
Date: Mon, 3 Aug 2015 15:39:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.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: [Caml-list] destructive local opens

Hi,

this is a small syntax suggestion which I thought I should share;
apologies if this is nonsense or has been already decided against.

Currently we have

let open! M in
...

to indicate that we do intend to shadow definitions in the current scope
by those in M. This avoids getting warning 44 on compilation. I find
that quite useful.

Would it be a good idea to have the same thing
for local opens with the dot syntax? M.(...) produces warning 44
currently, but a proposed new syntax

M.!(...)
or
M!(...)

or something of the kind would suppress it. Obviously it should not
interfere with references.

I came across this wish after defining a small Vector module which
overrides (+) to mean vector addition. Then formulas are conveniently
written M.(v + w) but that means I get 44. Of course I could define (+|)
instead but why not make use of namespaces if we can.