Re: Underscores in numbers for legibility
Lassi Kortela 13 Apr 2019 14:40 UTC
> I believe it is reasonable.
I am also in favor, barring unforeseen problems not yet discussed in
this thread.
Peter, how do you feel about the compatibility concerns in Chicken in
light of the discussion so far?
> I think. However, they are allowed in at least Ada, C#, Eiffel, Frink
> (the language
> of the Frink calculator), Java, Julia, Kotlin, OCaml, Perl, Python,
> Ruby, Rust, Swift.
> In Standard ML they are a common but nonstandard implementation extension.
> JavaScript has scheduled them for addition but they are not yet standard.
Wow, how do you manage to follow so many language communities in such
detail? Is it just passion and long experience or are there some
semi-official communication channels among standards people to pass
information like this from one language community to others?
> Cobol, true to its origins, allows commas instead; C++ uses apostrophe.
Those are interesting choices.
Comma-separated numbers are a minor disaster in any international
community since no-one can figure out where to use commas and where to
use periods and if there is even a difference... We Europeans are
continually confused by the use of commas in American software (and
sometimes even in European software that uses some weird mix of European
and American conventions).
Apostrophes are along the top of a line of text so they call to mind a
superscript (as ^ does). Another use is in feet and inches so they look
a bit like units of measure. Thank goodness underscore is the widespread
choice :)
> The JavaScript people made an interesting point: that when you allow
> both _ and quantifier suffixes, you must disallow _ as a leading character
> in suffixes, otherwise 1234_5 is ambiguous between 12345 and the
> quantity 1234 with (stupid) unit _5.
Does that imply we can go on with the current underscores proposal, and
then take that fact into account when/if a units-of-measure proposal is
made in the future?