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 -- 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
