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 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: References: <20250409142303.00004645@yahoo.com> <87ikndqabc.fsf@nosuchdomain.example.com> <20250410115501.000037a5@yahoo.com> <20250410080629.532@kylheku.com> <87a58mqt2o.fsf@nosuchdomain.example.com> <875xjaqmgf.fsf@nosuchdomain.example.com> <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 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.)