From: oliver <oliver@first.in-berlin.de>
To: David House <dhouse@janestreet.com>
Cc: "Gabriel Scherer" <gabriel.scherer@gmail.com>,
"Matej Košík" <5764c029b688c1c0d24a2e97cd764f@gmail.com>,
caml-list@inria.fr
Subject: Re: [Caml-list] syntactic detail
Date: Wed, 8 Feb 2012 14:58:18 +0100 [thread overview]
Message-ID: <20120208135818.GG1823@siouxsie> (raw)
In-Reply-To: <4F327CBF.4030005@janestreet.com>
On Wed, Feb 08, 2012 at 01:46:39PM +0000, David House wrote:
> On Wed 08 Feb 2012 01:39:26 PM GMT, oliver wrote:
> >I think the problem of being confounding 10_000_0000 with 100_000_000
> >or 10_000_0000 with 10_000_000 is less prominent then confounding
> >100000000 with 10000000.
> >
> >So this syntax rule already makes things much easier to read.
> >That's it's advantage.
> >
> >To have here all three characters as syntax rule could make sense,
> >but is less a problem than having no allowance of "_" in numbers at all.
>
> That is definitely true.
>
> >Might not be the case that pops up all to often,
> >but if so, it might be fine, if both values can be used:
> >
> > let startval_correct = 3.36639_92_6549992
> > let startval_wrong = 3.36639_29_6549992
> >
> >
> >So I have invented reasons why it's fine as it is.
>
> 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.
An int-value which raises an exception on overflow would be something
much more important than making this syntax rule more restricted.
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.
>
> >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 "_".
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.
But this might also be weird to you.
>
> Your example actually raises another point -- I'm not sure how my
> ideas would be extended to bits after the decimal place in floating
> point literals. Doing something like "every third character going
> right from the point" would probably be sufficient.
>
> >>I would prefer a syntax rule that only allows underscore every three
> >>characters (starting at the RHS of the number, i.e. complying to the
> >>usual convention). Well, certainly that for decimal literals. For
> >>hex literals you probably want to enforce the same, but every four
> >>characters.
> >[...]
> >
> >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...
Ciao,
Oliver
next prev parent reply other threads:[~2012-02-08 13:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 12:46 Matej Košík
2012-02-08 12:54 ` Gabriel Scherer
2012-02-08 13:09 ` David House
2012-02-08 13:39 ` oliver
2012-02-08 13:45 ` oliver
2012-02-08 13:46 ` David House
2012-02-08 13:58 ` oliver [this message]
2012-02-08 14:12 ` David House
2012-02-08 14:39 ` Gabriel Scherer
2012-02-08 14:50 ` David House
2012-02-08 15:19 ` Vincent Aravantinos
2012-02-10 8:39 ` Andrew
2012-02-08 16:30 ` oliver
2012-02-10 3:37 ` Jun Furuse
2012-02-08 16:21 ` oliver
2012-02-08 13:05 ` rixed
2012-02-09 9:05 ` Matej Košík
2012-02-09 10:56 ` Wojciech Meyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120208135818.GG1823@siouxsie \
--to=oliver@first.in-berlin.de \
--cc=5764c029b688c1c0d24a2e97cd764f@gmail.com \
--cc=caml-list@inria.fr \
--cc=dhouse@janestreet.com \
--cc=gabriel.scherer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox