Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <vtbc6o$1te2o$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com>
 <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com>
 <20250407210248.00006457@yahoo.com> <vt15lq$bjs0$3@dont-email.me>
 <vt2lp6$1qtjd$1@dont-email.me> <vt31m5$2513i$1@dont-email.me>
 <vt3d4g$2djqe$1@dont-email.me> <vt3iqh$2ka99$1@dont-email.me>
 <vt5fed$ccri$1@dont-email.me> <vt5js2$g1t7$1@dont-email.me>
 <20250409142303.00004645@yahoo.com> <87ikndqabc.fsf@nosuchdomain.example.com>
 <20250410115501.000037a5@yahoo.com> <vt8ei8$2vn84$1@dont-email.me>
 <20250410080629.532@kylheku.com> <vt94q5$3jjod$1@dont-email.me>
 <vt9628$3hhr8$3@dont-email.me> <vtammh$174ev$1@dont-email.me>
 <vtavn9$1dp7m$3@dont-email.me> <vtb8nv$1plb2$2@dont-email.me>
 <vtba81$1qfbm$1@dont-email.me>
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: <vtba81$1qfbm$1@dont-email.me>
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.