Re: do { quit; } else { }

On 13/04/2025 03:27, Janis Papanagnou wrote:

On 12.04.2025 13:00, bart wrote:

>
  []ref func(int) int := (F, G, H)  # [var name missing]
>
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 );

I can write it like this using anonymous functions:
   [10] PROC (INT) INT apfii;
   apfii[2:3] := ((INT i)INT:i-1, (INT i)INT:i+1);
   print((apfii[2](42), apfii[3](42)))
which is what I meant about having actual functions within the list. But I anyway consider this a higher level feature, and Algol68 is a higher level language. In my scripting language I can do:
     apfii := (2: {n:n-1}, {n:n+1})
     println apfii[2](42), apfii[3](42)
(Which despite being interpreted /and/ dynamic, runs 20 times faster than interpreted A68G.)

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.

'refs' occur in declarations. The equivalent 'deref' operation, '^' in my syntax, can be omitted in code when it is between terms. (So where C needs (*P)->m, I can just do P.m instead of P^^.m)
My style of coding also separates declarations, which have type annotatons, from code.
So my systems code is considerably cleaner than C. If you want really clean then you need to go to scripting languages with few type annotations and where most pointer/address-of ops are implicit.
(However, many are now introducing type annotations! Or have new languages such as Typescript created on top.)
Algol68 fits the role of systems language; it was famously impenetrable, and tried to do too much implicitly, so you had to spend time double-guessing what it might be up to. Implementation (if you had to create your own as I had to do), would have been quite impractical.

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.

I need 'ref' because I have a strict type system.
I anyway needed a fully transparent language because I first had to implement it on an 8-bit microprocessor.

- But as many
others here, I anyway don't care much about other's personal languages.

Neither do I. But I can at least appreciate (and appropriate) clever and useful features that they might have. Even more so if someone has managed to successfully use their product, instead of C, for a sustained period.
I will not dismiss a potentially useful feature because their product has not been 'battle-tested'.