Sujet : Re: do { quit; } else { }
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 11. Apr 2025, 16:24:08
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vtbc6o$1te2o$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
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.
do { quit; } else { }
Re: do { quit; } else { }