From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q18EeMLK031907 for ; Wed, 8 Feb 2012 15:40:22 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQBAAqIMk9KfVI0imdsb2JhbABDr2IIIgEBAQoJDQcSBiOBcgEBAQMBEgITGQEbHQEDAQsGBQsDCi4iAREBBQEcBhMIGodanDIKi3GCcIUNP4hzAgULi1AbBgEBASsMAoMLCDcIBwcCIgIhCx+DOgSVLY4ePYQD X-IronPort-AV: E=Sophos;i="4.73,383,1325458800"; d="scan'208";a="130591847" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Feb 2012 15:40:16 +0100 Received: by wgbds10 with SMTP id ds10so650372wgb.9 for ; Wed, 08 Feb 2012 06:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QbX5mFs/oWjdK9t2cD6NKQvps7PsWrhlFSjVnzcTTpE=; b=wxyGgkgxPSUMPnZoqTQAYbygq4Fwos1npkMQD4OVkFGTcTK28vBMHH5Z0Tm7Roohax O7PQzB8gBqT3Yj9xxxm7Ce34ZkVtdCebyqI3/N4PM2kSCbDTJV4lgZbbls+hHWZRUPVu AMjfzanupb1hjMW9LU5DmWM2b/UYy+9BrhVJQ= Received: by 10.180.7.231 with SMTP id m7mr34112647wia.3.1328712016310; Wed, 08 Feb 2012 06:40:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.42.208 with HTTP; Wed, 8 Feb 2012 06:39:36 -0800 (PST) In-Reply-To: <4F3282B1.1050205@janestreet.com> References: <4F326EA6.20900@gmail.com> <4F32741C.4040501@janestreet.com> <20120208133926.GC1823@siouxsie> <4F327CBF.4030005@janestreet.com> <20120208135818.GG1823@siouxsie> <4F3282B1.1050205@janestreet.com> From: Gabriel Scherer Date: Wed, 8 Feb 2012 15:39:36 +0100 Message-ID: To: David House Cc: oliver , =?UTF-8?B?TWF0ZWogS2/FocOtaw==?= <5764c029b688c1c0d24a2e97cd764f@gmail.com>, caml-list@inria.fr Content-Type: multipart/alternative; boundary=90e6ba211f1bbdb17d04b874df54 Subject: Re: [Caml-list] syntactic detail --90e6ba211f1bbdb17d04b874df54 Content-Type: text/plain; charset=ISO-8859-1 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 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. > --90e6ba211f1bbdb17d04b874df54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable People. Please. Tell me you are *not* arguing over underscores in numeric l= iterals !

> But it hides bugs, because if you see 10_000_0000 you= are
> much more=20 likely to think it is 10^7 than you are with 100000000,
> where you a= re=20 likely to be careful and take your time.

So your point is : it is da= ngerous because it is clearer. I also recommend we forbid comments, since:<= br>- 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 cons= ider writing a blog story!


On Wed, Feb 8, 2012 at 3:12 PM, David Ho= use <dhouse@j= anestreet.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 i= t hides bugs, because if you see 10_000_0000 you are much more likely to th= ink it is 10^7 than you are with 100000000, where you are likely to be care= ful 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 pr= obably barely anyone cares about. It's not a free restriction, but it i= s 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 =A0 1_000_000_000 instead of 10000000= 00.
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

=A0 =A04.526829898
=A0 vs.
=A0 =A04.5_26829898
=A0 vs.
=A0 =A04.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 coerci= ons:

module Two_dp_float : sig
=A0val of_float : float -> t
=A0val to_float : t -> float
end =3D struct
=A0type t =3D float
=A0let of_float x =3D x
=A0let to_float x =3D 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 re= strict 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.

--90e6ba211f1bbdb17d04b874df54--