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 q18DwP5N030028 for ; Wed, 8 Feb 2012 14:58:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsCAAh/Mk/AbSoIe2dsb2JhbABDhQ2oMoIrIgEBFiYEI4FyAQEEASNWEAsJBQoCAiYCAhQYMYgPA6dWkgQTgRyKIgICHQQGAS4ED4QVDQUEIIIkgRYEjWKHSpJf X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="143398753" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2012 14:58:20 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178010107.adsl.alicedsl.de [85.178.10.107]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q18DwJXe014346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 14:58:19 +0100 Received: by first (Postfix, from userid 1000) id E2043154022C; Wed, 8 Feb 2012 14:58:18 +0100 (CET) Date: Wed, 8 Feb 2012 14:58:18 +0100 From: oliver To: David House Cc: Gabriel Scherer , Matej =?utf-8?B?S2/FocOtaw==?= <5764c029b688c1c0d24a2e97cd764f@gmail.com>, caml-list@inria.fr Message-ID: <20120208135818.GG1823@siouxsie> References: <4F326EA6.20900@gmail.com> <4F32741C.4040501@janestreet.com> <20120208133926.GC1823@siouxsie> <4F327CBF.4030005@janestreet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F327CBF.4030005@janestreet.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] syntactic detail On Wed, Feb 08, 2012 at 01:46:39PM +0000, David House wrote: > 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. If something is a weird thing often lies in the eye of the beholder. An int-value which raises an exception on overflow would be something much more important than making this syntax rule more restricted. It's also somehow weird, to write 1_000_000_000 instead of 1000000000. Why should this weird "_" stuff supported at all? Writing +. instead of + also might be weird from a certain view. So you are using a weird language. > > >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. [...] But that case is just a typo, like it would be without any "_". For some rsearch it might make sense to delimit those digits which are officially rounded in a setting from those which might be rounded. like 4.526829898 vs. 4.5_26829898 vs. 4.52_6829898 and so on. So, even you have a floating point value with 9 digits after the decimal point, if you have a case where your official rounding is one or two digits, but you have to use the correct value, you could clarify this in the code. But this might also be weird to you. > > 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. Too late, if the four-digit rule would have been implemented before the (weird?) two-digit rule was asked by someone... Ciao, Oliver