Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Sun, 13 Apr 2025 00:09:23 +0100
Organization: A noiseless patient Spider
Lines: 109
Message-ID: <vterr3$1hme6$1@dont-email.me>
References: <vspbjh$8dvd$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> <vtbc6o$1te2o$1@dont-email.me>
 <vtbhjv$24api$1@dont-email.me> <vtbn2k$293r1$1@dont-email.me>
 <vtc19j$2kqlj$1@dont-email.me> <87a58mqt2o.fsf@nosuchdomain.example.com>
 <vtc7mp$2q5hr$1@dont-email.me> <875xjaqmgf.fsf@nosuchdomain.example.com>
 <vtcfhp$325g6$1@dont-email.me> <vtdql9$kspt$1@dont-email.me>
 <vte5o1$umr8$1@dont-email.me> <20250412101325.877@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 13 Apr 2025 01:09:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="52da66fb1217a688011ca6698ca24832";
	logging-data="1628614"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BXSeXUSvtVpH7iDSOdYeh"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xtWSzvM0JQ6QWQXZPmQkiDxlWnI=
In-Reply-To: <20250412101325.877@kylheku.com>
Content-Language: en-GB
Bytes: 6342

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