Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
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: <vtf7fe$1qtpg$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vt31m5$2513i$1@dont-email.me>
 <vt3d4g$2djqe$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> <vtcqf6$3j95s$1@dont-email.me>
 <vtdh4q$b3kt$1@dont-email.me>
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: <vtdh4q$b3kt$1@dont-email.me>
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