Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Fri, 4 Apr 2025 14:07:22 +0300 Organization: A noiseless patient Spider Lines: 97 Message-ID: <20250404140722.000063db@yahoo.com> References: <87y0wjaysg.fsf@gmail.com> <20250402220614.431@kylheku.com> <85mscxlqnb.fsf@nosuchdomain.example.com> <20250403121946.134@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Fri, 04 Apr 2025 13:07:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ba0cef8ce2c7ee9fc19ca675de21b3a2"; logging-data="3385625"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mto0qU1VcZIs11sB3vJfALBDHhsNW/ZI=" Cancel-Lock: sha1:W6ZrQxnoSC2F/aLhBD9r3Ly5RY0= X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32) Bytes: 5240 On Thu, 3 Apr 2025 19:37:31 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2025-04-03, BGB wrote: > > On 4/3/2025 1:12 AM, Keith Thompson wrote: > >> Kaz Kylheku <643-408-1753@kylheku.com> writes: > >>> On 2025-04-03, bart 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?