Re: [Caml-list] syntactic detail

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4109 bytes --]

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 <dhouse@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.
>

[-- Attachment #2: Type: text/html, Size: 6075 bytes --]