Re: [Caml-list] syntactic detail

[David House <dhouse@janestreet.com>]

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.