caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: octachron <octa@polychoron.fr>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: Nils Becker <nils.becker@bioquant.uni-heidelberg.de>,
	Caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] destructive local opens
Date: Mon, 3 Aug 2015 17:10:09 +0200	[thread overview]
Message-ID: <55BF8451.3060408@polychoron.fr> (raw)
In-Reply-To: <CAPFanBGu09VUy9UvHmU4_3FHyL_qQLvU35HWmt4PF-=8RCKAEw@mail.gmail.com>

Splitting 44 between alphanumeric and other identifiers is a nice 
default but it sounds a little arbitrary. Maybe it would make sense to 
combine this splitting with your [@shadow] annotation idea (cf. 
https://github.com/ocaml/ocaml/pull/218#issuecomment-123998749) ?

Like this, library writers could annotate identifiers that are intended 
to shadow predefined identifiers without any limitations, and cautious 
users could activate 53 to protect themselves from unexpected 
identifiers shadowing?

Regards,
octachron.

On 08/03/15 16:37, Gabriel Scherer wrote :
> We could split 44 in two warnings, one (52 ?) for alphanumeric
> identifiers and the other (53 ?) for symbol identifiers (infix and
> prefix operations, but also now the indexed read and write syntax),
> and enable 52 by default. The more paranoid people may then enable 53
> explicitly (and those that enable 44 explicitly today would retain the
> current behavior).
>
>
> On Mon, Aug 3, 2015 at 4:24 PM, Daniel Bünzli
> <daniel.buenzli@erratique.ch> 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.
>>
>> Best,
>>
>> Daniel
>>
>> [1] http://erratique.ch/software/gg
>>
>>
>>
>> --
>> 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


  parent reply	other threads:[~2015-08-03 15:10 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03 13:39 Nils Becker
2015-08-03 13:43 ` Thomas Refis
2015-08-03 13:45 ` Daniel Bünzli
2015-08-03 13:47   ` Daniel Bünzli
     [not found]     ` <55BF75F6.1040006@bioquant.uni-heidelberg.de>
2015-08-03 14:24       ` Daniel Bünzli
2015-08-03 14:37         ` Gabriel Scherer
2015-08-03 14:43           ` Daniel Bünzli
2015-08-03 15:10           ` octachron [this message]
2015-08-03 15:22             ` Daniel Bünzli
2015-08-03 16:13               ` octachron
2015-08-03 16:51                 ` Daniel Bünzli
2015-08-03 17:18                   ` Hendrik Boom
2015-08-03 17:59                   ` octachron
2015-08-06 13:23                     ` RE : " moreno pedro
2015-08-04  6:51         ` Petter Urkedal
2015-08-04  9:33           ` Goswin von Brederlow
2015-08-05  6:40             ` Petter A. Urkedal
2015-08-05 10:16               ` David Allsopp
2015-08-06  9:35               ` Goswin von Brederlow
2015-08-04 13:50           ` Hendrik Boom
2015-08-04  9:26         ` Goswin von Brederlow
2015-08-04  9:38           ` Daniel Bünzli
2015-08-04 12:26             ` vrotaru.md
2015-08-04 13:12               ` David Allsopp
2015-08-04 13:17                 ` Jeremy Yallop
2015-08-04 13:54                   ` vrotaru.md
2015-08-04 15:25                   ` Drup
2015-08-04 22:22                     ` vrotaru.md
2015-08-04 22:55                       ` Hendrik Boom
2015-08-05  4:52                         ` Gabriel Scherer
2015-08-04 13:14               ` Ivan Gotovchits
2015-08-14 10:55                 ` Goswin von Brederlow
2015-08-14 11:28                   ` Drup
2015-08-18 11:11                     ` Goswin von Brederlow
2015-08-18 12:52                       ` David Allsopp
2015-08-18 13:00                         ` Gabriel Scherer
2015-08-18 22:26                           ` Anthony Tavener
2015-08-19 13:55                             ` Oleg
2015-08-19 14:13                               ` John Whitington
2015-08-19 15:47                                 ` Hendrik Boom
2015-08-19 15:52                             ` Hendrik Boom
2015-08-19 18:09                               ` Anthony Tavener
2015-08-19 15:55                             ` Simon Cruanes
2015-08-19 16:42                               ` Arthur Wendling
2015-08-19 21:15                               ` octachron
2015-08-20  8:06                                 ` Romain Bardou
2015-08-20 17:03                                   ` Yotam Barnoy
2015-08-20 19:19                                     ` Erkki Seppala
2015-08-06  9:23               ` Goswin von Brederlow
2015-08-06  9:21             ` Goswin von Brederlow
2015-08-06 10:19               ` Daniel Bünzli
2015-08-06 13:36                 ` Hendrik Boom
2015-08-14 10:57                   ` Goswin von Brederlow
2015-08-17 10:17 Nils Becker
2015-08-17 14:26 ` Gabriel Scherer
2015-08-17 15:11   ` Nils Becker
2015-08-17 15:17     ` Drup
2015-08-17 15:18     ` Gabriel Scherer
2015-08-17 18:31       ` Hendrik Boom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55BF8451.3060408@polychoron.fr \
    --to=octa@polychoron.fr \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    --cc=nils.becker@bioquant.uni-heidelberg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).