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 17:21:34 +0100 [thread overview]
Message-ID: <20120208162134.GA4920@siouxsie> (raw)
In-Reply-To: <4F3282B1.1050205@janestreet.com>
On Wed, Feb 08, 2012 at 02:12:01PM +0000, 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.
Not sure if it's cheap.
Don't know how much effort it needs to implement it.
But also don't see if it really is that important.
>
> >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.
[...]
Orthogonal when looking at the features itself, but not when looking
at the importance of a need of the implementation.
>
> >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.
No.
of course +. must be used frequently, because it's the notation
that you need for float value addition.
So it's not a rare case; it's what you need to use when
you want to add float values in OCaml.
I doubt that most people only use int values in their code ;-)
>
> >>>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?
Yes.
The kind of type you have mentioned here seems to be based
in the allowance of "_" at all, or because you used that "_" feature
without being very used to the consequences of it, when changing code
is necessary.
More to that in a different mail.
>
> >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
[...]
I don't see where this addresses my example.
>
> 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.
Not sure if you know what I was talking about.
But maybe my example was misleading or not well explained.
>
> But more generally, I think it is worth more, in terms of bugs
> saved, to restrict the syntax versus allowing these
> infrequently-used cases.
[...]
Not sure if using "_" at all is done frequently.
Maybe a survey should clarify this; otherwise it's just a statement
on frequently used vs. not frequently used, based on your personal assumptions.
Ciao,
Oliver
next prev parent reply other threads:[~2012-02-08 16:21 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
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 [this message]
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=20120208162134.GA4920@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