Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Kaz Kylheku <643-408-1753@kylheku.com> Newsgroups: comp.lang.c Subject: Re: do { quit; } else { } Date: Sat, 12 Apr 2025 17:40:25 -0000 (UTC) Organization: A noiseless patient Spider Lines: 110 Message-ID: <20250412101325.877@kylheku.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 12 Apr 2025 19:40:25 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9f75a0c1dafb617c14742e67f05c9d3f"; logging-data="1032759"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/b2dCSI0bX+BnBZWqXrY0R0DFLesX9/bs=" User-Agent: slrn/pre1.0.4-9 (Linux) Cancel-Lock: sha1:iMZXSX+pGh7jUI3jQvlvPJ2XBcM= Xref: csiph.com comp.lang.c:392447 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. 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); the name would always be on the left, just after the declaration specifiers, and all the derivation would be postfix. 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. I'm just using it for syntax comparisons to illustrate that if all the type derviations are postfix, then precedence parentheses serve no purpose and we don't entertain them. 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. "Declaration follows use" might be even better with a nicer expression grammar in the area of arrays and pointers, but we don't have that. This (*a[10])(int) clump may seem difficult, but a C programmer cannot get around learning that same shape in the context of expressions, where it could occur like this (*a[i])(x + 1). If you grok this, you're most of the way toward grokking the declarator. There are some subtleties like expressions giving you various shortcuts. Arrays can be used as if they were pointers and vice-versa, and function pointers can be called without explicit dereferencing. I believe those additional rules in expressions that are not found in type derivation cause some C programmers to have difficulties with nested declarations. It's precisely because they cause deviations from "declaration follow use". The use of a function pointer is rarely observed as (*ptr)(arg) because ptr(arg) works, but the declarator must still be (*ptr)(paramtype) as if ptr(arg) didn't exist. If there were no deviations in "declaration follows use", such that calling a function pointer taken from an array had to be written (*a[i])(arg), then new C programmers would struggle less with declarations. Or should we say, struggle less with declarations of entities that they already know how to use. >> I have said multiple times that if I were to design a new programming >> language, its syntax would differ significantly from C's. > > But it would be a toy unless you could get it adopted by lots of people. > > By your standards, even a DSL that you create for use in your > professional work would be a toy. 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. A DSL that just transliterates some notation to a stable, mature language, according to a small body of rules, easily inherits the non-toy status from the platform it sits on. "Toy" is a not a well-defined concept, which mainly seems function as "not suitable for some unspecified purposes that I have in mind". People who use "toy" tend to move their secret goalposts. There are ways that a DSL could be unsuitable for some of the purposes it is supposedly designed for, even if it sits on a stable platform; then some people trying that DSL in earnest might abandon it and call it a toy. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca