Re: else ladders practice

On 04/11/2024 16:35, David Brown wrote:

On 03/11/2024 21:00, Bart wrote:

To my mind, this is a type of "multi-way selection" :
      (const int []){ a, b, c }[n];
 I can't see any good reason to exclude it as fitting the descriptive phrase.

And if "a", "b" and "c" are not constant, but require evaluation of some sort, it does not change things.  Of course if these required significant effort to evaluate,

Or you had a hundred of them.

or had side-effects, then you would most likely want a "multi-way selection" construction that did the selection first, then the evaluation - but that's a matter of programmer choice, and does not change the terms.

You still don't get how different the concepts are. Everybody is familiar with N-way selection when it involves actions, eg. statements. Because they will be in form of a switch statement, or an if-else chain.
They will expect one branch only to evaluated. Otherwise, there's no point in a selection or condition, if all will be evaluated anyway!
But I think they are less familiar with the concept when it mainly involves expressions, and the whole thing returns a value.
The only such things in C are the ?: operator, and those compound literals. And even then, those do not allow arbitrary statements.
Here is a summary of C vs my language.
In C, 0 or 1 branches will be evaluated (except for ?: where it is always 1.)
In M, 0 or 1 branches are evaluated, unless it yields a value or lvalue, then it must be 1 (and those need an 'else' branch):
                                         C     M
if-else branches can be exprs/stmts     Y     Y
if-else can yield a value               N     Y
if-else can be an lvalue                N     Y
?: branches can be exprs/stmts          Y     Y   (M's is a form of if)
?: can yield a value                    Y     Y
?: can be an lvalue                     N     Y   (Only possible in C++)
switch branches can have expr/stmts     Y     Y
switch can yield a value                N     Y
switch can be an lvalue                 N     Y
select can have exprs/stmts             -     Y   (Does not exist in C)
select can yield a value                -     Y
select can be an lvalue                 -     Y
case-select has exprs/stmts             -     Y
case-select can yield a value           -     Y
case-select can be an lvalue            -     Y
15 Ys in the M column, vs 4 Ys in the C column, with only 1 for value-returning. You can see why C users might be less familiar with the concepts.

I am very keen on keeping the concepts distinct in cases where it matters.

I know, you like to mix things up. I like clear lines:
   func F:int ...              Always returns a value
   proc P  ...                 Never returns a value

    int x = if (randomfloat()<0.5) 42;
>

 In C, no.  But when we have spread to other languages, including hypothetical languages, there's nothing to stop that.  Not only could it be supported by the run-time type system, but it would be possible to have compile-time types that are more flexible

This is a program from my 1990s scripting language which was part of my CAD application:
    n := 999
    x := (n | 10, 20, 30)
    println x
This uses N-way select (and evaluating only one option!). But there is no default path (it is added by the bytecode compiler).
The output, since n is out of range, is this:
    <Void>
In most arithmetic, using a void value is an error, so it's likely to soon go wrong. I now require a default branch, as that is safer.

and only need to be "solidified" during code generation.  That might allow the language to track things like "uninitialised" or "no value" during compilation without having them part of a real type (such as std::optional<> or a C

But you are always returning an actual type in agreement with the language. That is my point. You're not choosing to just fall off that cliff and return garbage or just crash.
However, your example with std::optional did just that, despite having that type available.

It doesn't return a value.  That is why it is UB to try to use that non-existent value.

And why it is so easy to avoid that UB.

My language will not allow it. Most people would say that that's a good thing. You seem to want to take the perverse view that such code should be allowed to return garbage values or have undefined behaviour.

 Is your idea of "most people" based on a survey of more than one person?

So, you're suggesting that "most people" would prefer a language that lets you do crazy, unsafe things for no good reason? That is, unless you prefer to fall off that cliff I keep talking about.
The fact is, I spend a lot of time implementing this stuff, but I wouldn't even know how to express some of the odd things in C. My current C compiler uses a stack-based IL. Given this:
   #include <stdio.h>
   int F(void){}
   int main(void) {
       int a;
       a=F();
       printf("%d\n", a);
   }
It just about works when generating native code (I'm not quite sure how); but it just returns whatever garbage is in the register:
   c:\cxp>cc -run t        # here runs t.c as native code in memory
   1900545
But the new compiler can also directly interpret that stack IL:
   c:\cxp>cc -runp t
   PC Exec error: RETF/SP mismatch: old=3 curr=2   seqno: 7
The problem is that the call-function handling expects a return value to have been pushed. But nothing has been pushed in this case. And the language doesn't allow me to detect that.
(My compiler could detect some cases, but not all, and even it it could, it would report false positives of a missing return, for functions that did always return early.)
So this is a discontinuity in the language, a schism, an exception that shouldn't be there. It's unnatural. It looked off to me, and it is off in practice, so it's not just an opinion.
To fix this would require my always pushing some dummy value at the closing } of the function, if the operand stack is empty at that point.
Which is sort of what you are claiming you don't want to impose on the programmer. But it looks like it's needed anyway, otherwise the function is out of kilter.

Note that I have not suggested returning garbage values - I have suggested that a language might support handling "no value" in a convenient and safe manner.

But in C it is garbage. And I've show an example of my language handling 'no value' in a scheme from the 1990s; I decided to require an explicit 'else' branch, which you seem to think is some kind of imposition.
Well, it won't kill you, and it can make programs more failsafe. It is also friendly to compilers that aren't 100MB monsters.

Totally independent of and orthogonal to that, I strongly believe that there is no point in trying to define behaviour for something that cannot happen,

But it could for n==4.

With justification. 0010 means 8 in C? Jesus.
>

 I think the word "neighbour" is counter-intuitive to spell.

EVERYBODY agrees that leading zero octals in C were a terrible idea. You can't say it's just me thinks that!

Once a thread here has wandered this far off-topic, it is perhaps not unreasonable to draw comparisons with your one-man language.

Suppose I'd made my own hammer. The things I'd use it for are not going to that different: hammering in nails, pulling them out, or generally bashing things about.
As I said, the things my language does are universal. The way it does them are better thought out and tidier.

The real problem with your language is that you think it is perfect

Compared with C, it a huge improvement. Compared with most other modern languages, 95% of what people expect now is missing.

    int F() {
        F(1, 2.3, "four", F,F,F,F(),F(F()));
        F(42);

It is undefined behaviour in C.  Programmers are expected to write sensible code.

But it would be nice if the language stopped people writing such things, yes?
Can you tell me which other current languages, other than C++ and assembly, allow such nonsense?
None? So it's not just me and my language then! Mine is lower level and still plenty unsafe, but it has somewhat higher standards.

If I were the designer of the C language and the maintainer of the C standards, you might have a point.  C is not /my/ language.

You do like to defend it though.

We can agree that C /lets/ people write messy code.  It does not /require/ it.  And I have never found a programming language that stops people writing messy code.

I had included half a dozen points that made C's 'if' error prone and confusing, that would not occur in my syntax because it is better designed.
You seem to be incapable of drawing a line beween what a language can enforce, and what a programmer is free to express.
Or rather, because a programmer has so much freedom anyway, let's not bother with any lines at all! Just have a language that simply doesn't care.