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
