From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q18DklKA029264 for ; Wed, 8 Feb 2012 14:46:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwBAGN7Mk8machzl2dsb2JhbABDhQ2oMoJNAQEBAQEIFgc7gXIBAQQBIxVAAQULCxgCAgUWCwICCQMCAQIBRQYNAQcBAYd4p1OSBIEvihwBBwICCQUNBAYBCwEIBQMDCQUMAgyCchkEAwwDFAWDL4EWBKgK X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="143396528" Received: from mx2.janestreet.com (HELO nyc-dmz-mxout2.janestreet.com) ([38.105.200.115]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2012 14:46:42 +0100 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1Rv7r6-0006tj-Fy; Wed, 08 Feb 2012 08:46:40 -0500 Received: from ldn-qws-011.delacy.com ([172.23.133.111]) by nyc-qsv-mail1.delacy.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rv7r6-0000C3-9K; Wed, 08 Feb 2012 08:46:40 -0500 Message-ID: <4F327CBF.4030005@janestreet.com> Date: Wed, 08 Feb 2012 13:46:39 +0000 From: David House User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: oliver CC: Gabriel Scherer , =?UTF-8?B?TWF0ZWogS2/FocOt?= =?UTF-8?B?aw==?= <5764c029b688c1c0d24a2e97cd764f@gmail.com>, caml-list@inria.fr References: <4F326EA6.20900@gmail.com> <4F32741C.4040501@janestreet.com> <20120208133926.GC1823@siouxsie> In-Reply-To: <20120208133926.GC1823@siouxsie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] syntactic detail On Wed 08 Feb 2012 01:39:26 PM GMT, oliver wrote: > I think the problem of being confounding 10_000_0000 with 100_000_000 > or 10_000_0000 with 10_000_000 is less prominent then confounding > 100000000 with 10000000. > > So this syntax rule already makes things much easier to read. > That's it's advantage. > > To have here all three characters as syntax rule could make sense, > but is less a problem than having no allowance of "_" in numbers at all. That is definitely true. > Might not be the case that pops up all to often, > but if so, it might be fine, if both values can be used: > > let startval_correct = 3.36639_92_6549992 > let startval_wrong = 3.36639_29_6549992 > > > So I have invented reasons why it's fine as it is. Perhaps this could happen. But I feel this could be expressed equally clearly using some other mechanism, like a comment. We don't have to have syntax-level support for every weird thing people would like to do. > Why should this case be forbidden? Because it is impossible to distinguish it from the wrongly-deliminated case that I described, which leads to the bugs I described. Your example actually raises another point -- I'm not sure how my ideas would be extended to bits after the decimal place in floating point literals. Doing something like "every third character going right from the point" would probably be sufficient. >> I would prefer a syntax rule that only allows underscore every three >> characters (starting at the RHS of the number, i.e. complying to the >> usual convention). Well, certainly that for decimal literals. For >> hex literals you probably want to enforce the same, but every four >> characters. > [...] > > For Hex it might also make sense to have it all two characters. > > If the rule would be only all 4 characters, that would be bad. Sure, this seems okay.