Re: do { quit; } else { }

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

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.
Notice that the 'type' keyword and the new identifier are outside of the type-spec, which is part of what makes C syntax a nightmare.

It would certainly have been possible to specify an order - either in the syntax or the constraints.  I think that would have been a good idea, and would make C code a little more consistent.  But by the time this was codified, there was probably a variety of orderings in use in real code, and such ordering would make the standard, and therefore the language, a little more complicated.
 

I missed out:
>
6 'int' can be optionally omitted in this case.
>
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."
What are those good reasons, that it makes code more readable? That it is easier to describe in a grammar? That it makes it easier to parse?
I've parsed C code; I can confirm it is much harder to do that any language I've devised.
Pretending for a minute that I have 'const' in my syntax, the example I posted would be written like this:
    type A = const u64
You can only define it once. The new name is ALWAYS on the left of the '=', unlike C, where here:
   typedef int (*A)[];
the name is in the middle of the 'int(*)[]' type.
If shared across multiple modules, then you'd write it like this (and not in a header either):
    global type A = const u64
*That* is simple. Remember you said this:
"C rarely makes things more complicated without a good reason."
And I responded woth this:
"C usually makes things more complicated without a good reason!"