Re: "A diagram of C23 basic types"

On 2025-04-03, BGB <cr88192@gmail.com> wrote:

On 4/3/2025 1:12 AM, Keith Thompson wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-04-03, bart <bc@freeuk.com> wrote:

On 02/04/2025 17:20, Scott Lurndal wrote:

Muttley@dastardlyhq.com writes:

On Wed, 2 Apr 2025 16:33:46 +0100
bart <bc@freeuk.com> gabbled:

On 02/04/2025 16:12, Muttley@DastardlyHQ.org wrote:

Meh.

>
What's the problem with it? Here, tell me at a glance the magnitude of
this number:
>
      10000000000

>
And how often do you hard code values that large into a program? Almost
never I imagine unless its some hex value to set flags in a word.

>
Every day, several times a day. 16 hex digit constants are very
common in my work.  The digit separator really helps with readability,
although I would have preferred '_' over "'".

>
Oh, I thought C23 used '_', since Python uses that. I prefer single
quote as that is not shifted on my keyboard. (My language projects just
allow both!)

>
I made , (comma) the digit separator in TXR Lisp. Nobody uses _ in the
real world.
>
I understand that in some countries, that is the decimal point.  That is
not relevant in programming languages that use a period for that and are
not localized.
>
Comma means I can just copy and paste a figure from a financial document
or application, or any other document which uses that convention.

 
The comma couldn't be used in C without the possibility of breaking
existing code, since 123,456 is already a valid expression, and is
likely to occur in a context like `foo(123,456)`.
 
C23 borrowed 123'456 from C++ rather than 123_456 (which I would have
preferred).  C++ chose 123'456 because the C++ already used the
underscore for user-defined literals.  Apparently some countries, such
as Switzerland, use the apostrophe as a digit separator.
 

>
In my compiler, I did both ' and _, ...
Personally though, I prefer using _ as a digit separator in these scenarios.
>
But, yeah, can't use comma without creating syntactic ambiguity.

False; you can't use comma because of an /existing/ ambiguity.

(In fact you could still use a comma; the "only" problem is you would
break some programs.  If this is your own language that nobody else
uses, that might not be a significant objection.)

When you've designed the language such that f(1,234.00) is a function
call with two arguments, equivalent to f(1, 124.00), that's where
you created the ambiguity.

Your rules for tokenizing and parsing may be unambiguous, but it's
visually ambiguous to a human.

You should have seen it coming when allowing comma punctuators to
separate arguments, without any surrounding whitespace being required.

Now you can't have nice things, like the comma digit separators that
everyone uses in the English speaking world that uses . for the
decimal separators.

By the way ...

One programming language that has comma separators is Fortran,
by the way.  Fortran persisted in providing this feature in spite of
shooting itself in the foot with ambiguities.

When Fortran was being designed, people were naive in writing
compilers. They thought that it would simplify things if they
removed all spaces from the code before lexically scanning it and
parsing.

Thus "DO I = 1, 10" becomes "DOI=1,10" and "FO I = 1, 10"
becomes "FOI=1,10"

After that you have to figure out that "DOI=1,10" is the
header of a DO loop which steps I from 1 to 10,
whereas "FOI=1,10" assigns 110 to variable FOI.

Removing spaces before scanning anythning is a bad idea.

Not requiring spaces between certain tokens is also a bad idea.

In the token sequence 3) we wouldn't want to require a space
between 3 and ).

But it's a good idea to require 1,3 to be 1, 3 (if two numeric
tokens separated by a comma are intended and not the
number 1,3).

Commas are "fluff punctuators". They could be removed without
making a difference to the abstract syntax.

Fun fact: early Lisp (when it was called LISP) had commas
in lists. They were optional. (1, 2, 3) or (1 2 3). Your
choice.

Comma separation causes problems when arguments can be empty!

In C preprocessing MAC() is actually a macro with one argument,
which is empty. MAC(,) is a macro with two empty arguments
and so on.  You cannot write a macro call with zero arguments.

Now, if macros didn't use commas, there wouldn't be a problem
at all: MAC() -> zero args; MAC(abc) -> one arg;
MAC(abc 2) -> two args.

Wow, consistency. And no dangling comma nonsense to deal with in
complex, variadic macros!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca