Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou Newsgroups: comp.lang.c Subject: Re: do { quit; } else { } Date: Sun, 13 Apr 2025 04:27:57 +0200 Organization: A noiseless patient Spider Lines: 111 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Date: Sun, 13 Apr 2025 04:28:13 +0200 (CEST) Injection-Info: dont-email.me; posting-host="37bc21190f4ec23076b19d75e9f1a003"; logging-data="1931056"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jElcgQdn1TJBevy6b/MAG" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cancel-Lock: sha1:WeEtQfEQRAaysTBfHVtBTC7rxiw= X-Enigmail-Draft-Status: N1110 In-Reply-To: Bytes: 5961 On 12.04.2025 13:00, bart wrote: > On 12/04/2025 05:33, Janis Papanagnou wrote: >> [ 'typedef' composition/decomposition for complex declarations ] > > This is a third kind of workround. All of them should be unnecessary. > Unless the type really is complicated and needs to be decomposed anyway, > whatever the syntax. Well, yes. If you have a somewhat [IMO] convoluted syntax then you pick your language choices to address it and do the best out of it. > [...] > > But I also 100% hate its syntax and various other bits and pieces. (OK, > about 80% then.) (I also don't like its syntax too much. I think I'm just complaining less than you about that. BTW, I've got the impression that all the shortcomings of "C" are well known by most regulars here; they just handle these facts in discussions differently than you.) > [... > > And APIs use C type syntax. So, yeah, I am entitled to an opinion about it. That's fine. Although those repeated complaints also annoy me. (But that's my problem, of course.) > [...] > >> Guessing: An array with 10 elements that are pointers to functions >> that take an 'int' parameter and return an 'int' value? >>> [...] >> >> (This opening parenthesis syntactically indicates the function, as >> also indicated by the numberings above. - Or so I'd think. - No?) > > Not necessarily. This is a valid declaration in C: > > int (A); > > That opening parentheses is just noise. (I guess you just learned > something new about C today?) Not really. - I was merely pointing out that the messages you posted made sense to me; where I had the impression you were confused about it. > >> Assumed that my guess above was correct that's quite equivalent to >> the Algol 68 form >> >> [10] REF PROC (INT) INT a > > So you do get it (maybe I should have read this far first). Yes, it > directly comes from Algol68. > > But left-to-right type specifications must be common now everywhere. Not sure. A more regular syntax is at least something I appreciate a lot. (That' why, maybe many months ago, I spoke here about Algol 68 as one the formally most consistent languages, and that I like it a lot because of that.) > >> 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! > > This is not as clear; the intent is to have a reference to a function; > not an array of actual functions. For example: > > []ref func(int) int := (F, G, H) > > It is initialised to functions F, G, H which are defined elsewhere. In Algol 68 I can just write (without 'REF'), for example, [10] PROC (INT) INT apfii; PROC one_less = (INT i) INT : i-1; PROC one_more = (INT i) INT : i+1; apfii[2:3] := ( one_less, one_more ); We don't need "pointers" (or references) which don't contribute to the clearness of the semantics for this purpose - 'REF's are used for other things -, for the case here they'd rather introduce low-level mechanics unnecessarily in the application. - Just saying. (I'm not intending to complain in that respect about "C" or about "your language". I'm merely reporting some simple facts about it.) - So the 'ref' necessity in your language may look clear to you but for me it's just obscuring ballast. > Maybe in Algol68 you can have actual function definitions in that list. Yes. It makes no sense to unnecessarily expose low-level implementation mechanics to the programmer. (I think Algol 68 does that quite well.) > But not in mine, which was created as a leaner, simpler and more > transparent systems language. We obviously disagree about the "transparence". I prefer languages that don't make me have to use unnecessarily low-level mechanics. There's no necessity of "ref" here; that's a problem of (or a "solution" or maybe "workaround" in, or a design decision of) your language. - But as many others here, I anyway don't care much about other's personal languages. Janis