People. Please. Tell me you are *not* arguing over underscores in numeric literals !
> 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. So your point is : it is dangerous because it is clearer. I also recommend we forbid comments, since: - they can be abused, even by mistake, to make code *harder* to read - removing them will force people to read code more carefully I'm out of this discussion. PS: Planet OCaml needs some love. If you're considering contributing to the present debate, please also consider writing a blog story! On Wed, Feb 8, 2012 at 3:12 PM, David House <dho...@janestreet.com> 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. > > > 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. > > > 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. > > > 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? > > > 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 > > 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. > > But more generally, I think it is worth more, in terms of bugs saved, to > restrict the syntax versus allowing these infrequently-used cases. > > > 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... >> > > You're right, that would be a change that would probably break a lot of > code. I claim my suggestion would not break much code. > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
