Re: "A diagram of C23 basic types"

On Thu, 3 Apr 2025 19:37:31 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

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

>
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.
 

That not precise. According to Wikipedia, comma is not used as
group separator in South Africa.
Anyway, both international standardization bodies and standardization
bodies of majority of English speaking countries, including USA, oppose
such use of comma. They recommend thin space where available and either
regular space or nothing at all when thin space is not available.

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!
 

What exactly do you advocate? For comma to make no significance at all
in all contexts except within string literal? With space as replacement
in all contexts? Or in all contexts except comma operator?