Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: Re: do { quit; } else { } Date: Fri, 11 Apr 2025 17:24:08 +0200 Organization: A noiseless patient Spider Lines: 128 Message-ID: References: <8634enhcui.fsf@linuxsc.com> <86ldsdfocs.fsf@linuxsc.com> <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com> <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com> <20250407210248.00006457@yahoo.com> <20250409142303.00004645@yahoo.com> <87ikndqabc.fsf@nosuchdomain.example.com> <20250410115501.000037a5@yahoo.com> <20250410080629.532@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 11 Apr 2025 17:24:09 +0200 (CEST) Injection-Info: dont-email.me; posting-host="414a89bbcf5f663aa3944451ac130353"; logging-data="2013272"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fZUIVkm4LCcwxsQuIVbUGYrJahhHVksM=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:nmgb0aOfS3L4rA5dCLKD/U1Ox/Q= Content-Language: en-GB In-Reply-To: Bytes: 6569 On 11/04/2025 16:50, bart wrote: > On 11/04/2025 15:25, David Brown wrote: >> On 11/04/2025 13:51, bart wrote: >>> On 11/04/2025 10:17, David Brown wrote: >>>> On 10/04/2025 21:27, bart wrote: >>>>> On 10/04/2025 20:05, David Brown wrote: >>> >>>>>> C rarely makes things more complicated without a good reason. >>>>> >>>>> C usually makes things more complicated without a good reason! >>>> >>>> Nope. >>>> >>>>> >>>>> Here's one example, of dozens, of perfectly legal C: >>>>> >>>>>    long unsigned const long const const typedef int A; >>>>>    int long unsigned const long const const typedef A; >>>>>    long unsigned const long const typedef int A; >>>>>    ..... >>>>> >>>> >>>> That is not more complicated, nor is it without good reason. >>> >>> Huh? That demonstrates several things: >>> >>> 1 That the same identifier can be redeclared multiple times >> >> Many types of declarations can be repeated, as long as they define the >> same identifier to be the same thing.  If you want the details, they >> are in section 6.7 of the standard. >> >>> >>> 2 That 'typedef' needn't be on the left, but can be anywhere in the >>> middle of a type spec >> >> Correct.  Putting it anywhere other than the left may be disallowed >> sometime in the future (it is an "obsolescent feature"), but it is >> currently supported in C. >> >>> >>> 3 That 'const' can also be anywhere inside the type spec >> >> Correct. >> >>> >>> 4 That duplicate 'const's are tolerated >> >> Correct. >> >>> >>> 5 That the three tokens ('int', 'unsigned' and two 'long's) denoting >>> the type can be be any order (and mixed up with other attributes) >>> >> >> Correct. >> >> You seem to think that allowing a variation in the way a declaration >> is made makes the feature "more complicated".  That is simply >> incorrect. The feature - the syntax and the rules in the language >> definition - are /less/ complicated because of this flexibility.  It >> means the syntax here can be, as given in 6.7p1 : >> >> declaration-specifiers: >>      storage-class-specifier declaration-specifiers opt >>      type-specifier declaration-specifiers opt >>      type-qualifier declaration-specifiers opt >>      function-specifier declaration-specifiers opt >>      alignment-specifier declaration-specifiers opt > > That always reads to me like 'lots of twisty windy passages, all alike'. Try reading it without your usual anti-C prejudice. Perhaps read the whole section of the standard. > >> If the order were to be strictly specified, there would need to be a >> half-dozen more named and defined specifier lists in the syntax. > > This is the similar feature for my syntax, a bit of BNF: > >   typedef = [scopeattr] 'type' name = typespec > > It does a bit more than C's 'typedef' in that such names can be > exported, to render them visible to modules that import this one. > The C syntax for declarations here is for /all/ declarations in C. It's not just for typedefs in a simple little toy language. (And yes, if you are going to make absurd claims about your language in comparison to C, you can expect to hear that it is a toy in comparison C.) >>> >>> That makes it pretty complicated to me! And I can't see that any of >>> these are necessary. >> >> No one suggested it was at all necessary. > > /You/ did: "That is not more complicated, nor is it without good reason." You just quoted me - at no point did I say it was "necessary". Are you still surprised that sometimes people say you are trolling or lying? I didn't give the slightest reason to suggest the syntax of C's declarations was necessary. Nor did I suggest that I like C's rules here - on the contrary, I have made it clear that I'd prefer a stricter ordering. But C is not a language I designed, nor is it designed for my needs alone. > > What are those good reasons, that it makes code more readable? That it > is easier to describe in a grammar? That is, as I have already said, a good reason for this. It is also more flexible - some people like that. Remember also that not all C code is written out by hand - some is generated, some is also the result of macro expansion. It is a language designed to work well for a vast number of people in a vast number of circumstances - not a plaything for a single person. > That it makes it easier to parse? > Who cares? That's irrelevant to the language design, except for toys where the only user is the person who writes the tools.