Re: do { quit; } else { }

bart <bc@freeuk.com> writes:

>
Rubbish. Everyone finds C declaration syntax a nightmare.

There's people (also a couple regulars in this Usenet group) that are
constructing sentences of various generalizing forms (like yours, and
also with other forms and contents; like concerning tools, people).

I think it should be unnecessary to say that such sentences are often
just projections, or wishful thinking, or unnecessary rhetoric moves,
rarely backed up by facts, and typically also just not true (at least
in their typical absolute and generalized form).

On 11/04/2025 22:36, Keith Thompson wrote:

>
Rubbish.  I find C declaration syntax annoying, not a "nightmare".

There's so many attributes!

I (for example) think they're (in some respects) "badly designed".

On 12.04.2025 01:13, bart wrote:

>
Annoying would be having to get letter case or punctuation just right.

Are you now _defining_ what "annoying" *commonly* means? Or what it
*has to* mean [in your opinion]?

Please try to decouple your personal sight from the clear facts and
formulate your statements appropriately. - Unless your intention is
to just inflict communication disruptions.

 
But C typepecs can go far beyond it. I can just about do arrays of
pointers, or pointers to arrays. Anything more complicated is pretty
much trial and error.

I understand you have problems with it. And I'm not astonished...

 
In an example in my post which I then deleted (DB will just ignore
examples), I wanted to create an array of 10 pointers to functions that
take an int and return an int.

Because of "C"'s somewhat convoluted (IMO "bad") syntax it might
help you to make use of 'typedef's to incrementally construct your
types! - That's at least what I did when I wanted to create better
legible "C" code in cases of overly complex type structures. - It's
also a general method to handle complexity.

 
I started with something like this that I recalled from memory
(otherwise it would be even more wrong):
 
 int (*A)[10](int);
 
but CDECL said it was something different. I tried one or two more
combinations before I gave up and asked CDECL to tell me the type from
the English.
 
C type syntax is just not fit for purpose.

Reality shows that it *is* (de facto) "fit for purpose". (Probably
not yours. - I'm still wondering why you act in a "C" newsgroup.)

This is not how a language is
meant to work, and this is not supposed to be the hard part of a
language! Syntax should be the easy bit.

I agree that language designers can do a much better job. (There's
quite some examples for languages with an IMO "better" syntax.)

 
This is that English spec (with the significant bits numbered):
 
  array 10 pointer to func take int return int

My English might not be good enough, but in my book this is not an
English sentence and for me not (not much) easier to understand than
the "C" syntax below; the latter can at least (with its formality!)
be _understood_ by an experienced "C" programmer as a well defined
code pattern.

Guessing: An array with 10 elements that are pointers to functions
that take an 'int' parameter and return an 'int' value?

    1    2   3         4         5         6
 
Here is what CDECL came up with:
 
   int (*A[10])(int);
   6    3 1 2  4 5          (Not sure which bit is the '4')

(This opening parenthesis syntactically indicates the function, as
also indicated by the numberings above. - Or so I'd think. - No?)

 
The numbers below show the correspondence with the English. You can see
it's all over the place. This is how I'd write it in another actual
language syntax:
 
   [10]ref func(int)int A
   1 2 3   4    5   6

And what should that mean? - You know, since I haven't identified
your "English sentence" as a clearly understandable English sentence
I'm lost here, since I don't know that (your?) language. - For the
"C" case I could at least read the "C" specs (in case I got lost).

Assumed that my guess above was correct that's quite equivalent to
the Algol 68 form

  [10] REF PROC (INT) INT a

but in Algol 68 you'd probably rather use it without the unnecessary
"pointer"/reference just as in

  [10] PROC (INT) INT a

which - as you seem to like clearness - is even simpler!

 
Notice that that numbering here exactly corresponds to the English. THIS
is how easy it should be. I could write this as fast as I can type.
 
Further, the variable name is well out of it. In my syntax, any names go
on the right; names on the left is also popular. But no language other
than C and C++ has names IN THE MIDDLE.

Yes, as said, this mixing I also think to have been bad idea. - But
the "C" language was originating in a culture where people seem to
think that mixing date components (like "April 12th 2025") is also
natural[*] or at least an appropriate usable representation. :-)

[*] I have an idea how it came to that format, but that's speculation.

 
So, yeah, a 'nightmare' is more apt than 'annoying'.

Again, ITYM "for you". - Yes, we know that.

Use type compositions (in case you are actually programming in "C")!

Janis