Re: text in programming languages, Unicode in strings

Anton Ertl wrote:

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

Scott Lurndal wrote:
 

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

MitchAlsup1 wrote:

 

And I miss some equivalent of picture clauses in C every time I

see, >> > including in this NG, a number consisting of a string of
say 8 or 9 >> > or more digits without the every three digit
separator character, >> > which sure makes reading such numbers
easier.  :-( >>

printf has supported that capability for decades.
 
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535)  * 67.61 + 2295 * 173.35  + 3230 * 191.00 + 192 *

750.15 + >> 150 * 509.85 + 254 * 6> 2,505,496.61

 
If the mechanisms that you and Anton present were so easily
available, why do I see so many instances of "non separated"
outputs?

 
What locale are you using?

I happen to be in the US, however . . . 


When I mentioned "in this NG", I meant posts that present the outputs
of some similation program, reduced trace data, GREP output, etc.  I
certainly don't want to deprecate such posts, as clearly having actual
data is better than even informed guesses or opinions.  And,in regards
to locale, I can handle just fine, numbers presented with just about
any reasonable separator - I am not insisting on commas. But I suspect
that most readers in this news group would be happy with either commas
or periods, spaces, underscore, etc. The key is something versus
nothing.

 

Are they
too recent,

 
SUSv3 is from 2001.  But have Windows implementations of printf and
scanf implemented the "'" flag?  If so, when?
 

or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?

 
An alternative explanation is that programmers believe that users care
that the output of the program can be used as input to programs with a
minimum of fuss.

Good point. 

There are two difficulties here:
 
* There are likely programs that do not understand input with
  thousands separators.  This includes the printf program shown above
  at least as supplied with Debian 12.  So if a program outputs
  thousands separators, there may be difficulties in feeding that to
  downstream programs.
 
* The text representation becomes locale-specific:
 
  [b3:~:105507] LC_NUMERIC=en_US printf "%'10d\n" 505496
     505,496
  [b3:~:105508] LC_NUMERIC=de_AT printf "%'10d\n" 505496
     505.496
 
  Note that the first output would be interpreted as 505496E-3 in the
  de_AT locale, and the second would also be interpreted as 505496E-3
in   the en_US locale.
 
Therefore I think that we need some locale-independent thousands (and
decimal) separators.

Fair enough.

For the decimal separator every programming
language uses ".".

Do they?  I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may have
the syntax wrong), then the decimal speparator became the comma.
Perhpa this wasn't brought forward.  But then if you use the period for
the three digits separator and the decimal separator, doesn't that
cause confusion?

For the thousands separator, Ada, C#, D, Eiffel,
Go, Haskell, Java, Julia, Perl, Python3, Ruby, Rust, and Swift use _.
And Gforth, too.
 
In C++, there is a conflict of _ with another feature, so they instead
chose '.  However, C++ is not used interactively, and in a code
generator that generates C++ code, having to replace _ with ' for
generating C++ code is a minor pain.
 
- anton

--
 - Stephen Fuld
(e-mail address disguised to prevent spam)