Re: do { quit; } else { }

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