Re: do { quit; } else { }

On 12/04/2025 18:40, Kaz Kylheku wrote:

On 2025-04-12, bart <bc@freeuk.com> wrote:

On 12/04/2025 14:43, David Brown wrote:

On 12/04/2025 03:27, bart wrote:

>

C type syntax is famous for being difficult and confusing; I think
most will agree about that. Even the creators said so.

>
I disagree with that claim.  I think it is probably fair to say that
advanced, complicated and multi-layer types are difficult in any
programming language.

>
But a type that is a simple linear chain should be straightforward, and
usually is, just not in C. That was illustrated here:
>
    array of 10 pointer to function taking int and returning int
      1      2    3           4             5         6

 You make a good point in that since the type constructing operators are
unary (prefix or postfix), the derivation chain is linear and could be
linearized, without the need for any precedence parentheses.
 It follows the use, though.

You still seem keen on making typespec syntax somehow match expression syntax. I think that's a mistake. Type syntax is not executed, not at this level of language.

The function and array derivations are postfix. Only the pointer
derivation is prefix.
 If we imagine a C with postfix pointer dereferencing, say using ^
(setting aside the xor meaning for a moment), like:
    a[i]^(arg); // index into a at i, dereference, call with arg.

Then the declarator would be similar under declaration-follows-use:

   int a[10]^(int); // same as int (*a[10])(int);

Your example /still/ has type syntax that looks like an expression; they are easy to confuse. You WANT a type syntax that is more distinct.

Then, suppose if you didn't want an array of pointers, but
a pointer to an array, you would not add, remove or rearrange
precedence parentheses. You would just reorder the postfixes.

   int a^[10](int) // same as int (*a)[10](int);
                   // Note: invalid! For syntactic discussion only!
 This is a type not supported in C: array of functions.

Yes, you'd move 'pointer to' symbol along. Or just add a new one. With postfix deref, you don't need to bother with round brackets (which was always a bizarre idea to me; normally brackets are used around parameter lists only.

You do have a point, but the fact that C declarations follow C
expressions (even with the way suboptimal dereferencing is on the left)
is a good thing. The consistency makes it easy to learn declarations,
and also to visually check code for sanity: do declarations match uses.

I've tried for decades but still find them impossible without external help. Obviously for me it doesn't work.
But, what the hell is there are learn anyway?! Typespecs are built out of primitive types, arrays, pointers and function signatures.
If your type is a pointer to array of pointer to T, then you just write a pointer to array of T! That is:
    *[]*T X
in my LTR syntax from earlier today. Then access to the T element is with X*[i]*.
Here the ordering of those ops (deref, index, deref) does match the ordering of the corresponding type elements, but I'm not making a big deal out of that, to the extent that the syntax must match exactly. It won't do since X is on the opposite end for a start.
In my real language, the type is:
    ref[]ref T X
and the term is X[i]^. (The ^ between X and [ can be implicit.)
Notice that while the ordering is similar, there is no attempt to match syntax. It is not necessary. I can't mistake one for the other, either.

If the DSL reinvents a lot of risky wheels, like doing everything
from scratch, that could be the case. It takes some years to mature
something out of non-toy status at that level.

My point was that a DSL is just another piece of custom software. But such software in general is not a toy because it has not been 'battle-tested'. It will have the usual testing processes so that it meets its specs for client's application.
My language was just another tool that worked remarkably well. It was not a general language intended for a mass market.
But DB refuses to acknowledge any ideas that come out of it and will always insist that C is better. (I guess he would lend more credence to some hypothetical feature that has not been implemented and has never been proved.)