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 q18GLfSn003216 for ; Wed, 8 Feb 2012 17:21:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkBAMefMk/AbSoIhWdsb2JhbABEhQ2oBoIrIgEBAQoLCxsEI4FyAQEEARgLBFIQCwkFCgICJgICFBgxiA8Dp1OSAhOBHIoiAgIdBAYBLgQPhBUNBQQggiQzYwSNYodKkl8 X-IronPort-AV: E=Sophos;i="4.73,384,1325458800"; d="scan'208";a="143424218" 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 17:21:36 +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 q18GLYP8026528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 17:21:35 +0100 Received: by first (Postfix, from userid 1000) id B5386154022C; Wed, 8 Feb 2012 17:21:34 +0100 (CET) Date: Wed, 8 Feb 2012 17:21:34 +0100 From: oliver To: David House Cc: Gabriel Scherer , Matej =?utf-8?B?S2/FocOtaw==?= <5764c029b688c1c0d24a2e97cd764f@gmail.com>, caml-list@inria.fr Message-ID: <20120208162134.GA4920@siouxsie> References: <4F326EA6.20900@gmail.com> <4F32741C.4040501@janestreet.com> <20120208133926.GC1823@siouxsie> <4F327CBF.4030005@janestreet.com> <20120208135818.GG1823@siouxsie> <4F3282B1.1050205@janestreet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F3282B1.1050205@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 02:12:01PM +0000, David House wrote: > On Wed 08 Feb 2012 01:58:18 PM GMT, oliver wrote: > >>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. > > My definition of "weird" is "few people use this in practice". > > Clearly, delimiting groups of thousands is useful to a lot of > people. But it hides bugs, because if you see 10_000_0000 you are > much more likely to think it is 10^7 than you are with 100000000, > where you are likely to be careful and take your time. We can > prevent this by more stringent syntax rules. This would also prevent > some corner cases that you have described, that probably barely > anyone cares about. It's not a free restriction, but it is cheap, > and definitely has value. Not sure if it's cheap. Don't know how much effort it needs to implement it. But also don't see if it really is that important. > > >An int-value which raises an exception on overflow would be something > >much more important than making this syntax rule more restricted. > > That's completely orthogonal. [...] Orthogonal when looking at the features itself, but not when looking at the importance of a need of the implementation. > > >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. > > I think this is addressed by my definition of "weird" above. No. of course +. must be used frequently, because it's the notation that you need for float value addition. So it's not a rare case; it's what you need to use when you want to add float values in OCaml. I doubt that most people only use int values in their code ;-) > > >>>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 "_". > > I don't understand. Wouldn't it be better to have a syntax where it > is harder to make typos? Yes. The kind of type you have mentioned here seems to be based in the allowance of "_" at all, or because you used that "_" feature without being very used to the consequences of it, when changing code is necessary. More to that in a different mail. > > >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. > > This could also be done, by, e.g., defining a new type with explicit > coercions: > > module Two_dp_float : sig > val of_float : float -> t > val to_float : t -> float > end = struct > type t = float > let of_float x = x > let to_float x = x > end [...] I don't see where this addresses my example. > > This actually enforces that you get the notation right in your code, > rather than with the underscores, where you could typo and put the > underscore too far right, or forget to put them in all together. Not sure if you know what I was talking about. But maybe my example was misleading or not well explained. > > But more generally, I think it is worth more, in terms of bugs > saved, to restrict the syntax versus allowing these > infrequently-used cases. [...] Not sure if using "_" at all is done frequently. Maybe a survey should clarify this; otherwise it's just a statement on frequently used vs. not frequently used, based on your personal assumptions. Ciao, Oliver