Re: else ladders practice

On 02/11/2024 11:41, David Brown wrote:

On 01/11/2024 20:47, Bart wrote:

On 01/11/2024 18:47, David Brown wrote:

On 01/11/2024 19:05, Bart wrote:

On 01/11/2024 17:35, David Brown wrote:

>

>
What you have written here is all correct, but a more common method would be to avoid having three printf's :
>
void shout_a_number(int n) {
     printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
}
>
That's more likely to match what people would want.

>
I was also trying to show that all elements are evaluated, so each has to have some side-effect to illustrate that.

>
Fair enough.
>

>
A true N-way-select construct (C only really has ?:) would evaluate only one, and would deal with an out-of-range condition.

>
That's a matter of opinion and design choice, rather than being requirements for a "true" select construct.

>
I don't think it's just opinion.

 Yes, it is.

Then we disagree on what 'multi-way' select might mean. I think it means branching, even if notionally, on one-of-N possible code paths.
The whole construct may or may not return a value. If it does, then one of the N paths must be a default path.

I don't disagree that such an "select one of these and evaluate only that" construct can be a useful thing, or a perfectly good alternative to to an "evaluate all of these then select one of them" construct.  But you are completely wrong to think that one of these two is somehow the "true" or only correct way to have a selection.
 In some languages, the construct for "A or B" will evaluate both, then "or" them.  In other languages, it will evaluate "A" then only evaluate "B" if necessary.  In others, expressions "A" and "B" cannot have side-effects, so the evaluation or not makes no difference.  All of these are perfectly valid design choices for a language.

Those logical operators that may or may not short-circuit.
One feature of my concept of 'multi-way select' is that there is one or more controlling expressions which determine which path is followed.
So, I'd be interested in what you think of as a multi-way select which may evaluate more than one branch. Or was it that 'or' example?

>
In general, an if-else-if chain (which was the point of the OP), would evaluate only one branch.

 It evaluates all the conditionals down the chain until it hits a "true" result, then evaluates the body of the "if" that matches, then skips the rest.

I don't count evaluating the conditionals: here it is the branches that count (since it is one of those that is 'selected' via those conditionals), and here you admit that only one is executed.

(Of course generated code can evaluate all sorts of things in different orders, as long as observable behaviour - side-effects - are correct.)
 

So would a switch-case construct if sensibly implemented (in C's version, anything goes).
>

 C's switch is perfectly simply and clearly defined.  It is not "anything goes".  The argument to the switch is evaluated once, then control jumps to the label of the switch case, then evaluation continues from that point.  It is totally straight-forward.

It's pretty much the complete opposite of straightforward, as you go on to demonstrate.
C 'switch' looks like it might be properly structured if written sensibly. The reality is different: what follows `switch (x)` is just ONE C statement, often a compound statement.
Case labels can located ANYWHERE within that statement, including within nested statements (eg. inside a for-statement), and including 'default:', which could go before all the case labels!
The only place they can't go is within a further nested switch, which has its own set of case-labels.
Control tranfers to any matching case-label or 'default:' and just keeps executing code within that ONE statement, unless it hits 'break;'.
It is totally chaotic. This is what I mean by 'anything goes'. This is a valid switch statement for example: 'switch (x);'.
You can't use such a statement as a solid basis for a multi-way construct that returns a value, since it is, in general, impossible to sensibly enumerate the N branches.

You might not like the "fall-through" concept or the way C's switch does not quite fit with structured programming.  If so, I'd agree entirely.

Good.

The requirement for lots of "break;" statements in most C switch uses is a source of countless errors in C coding and IMHO a clear mistake in the language design.  But that does not hinder C's switch statements from being very useful, very easy to understand (when used sensibly), and with no doubts about how they work (again, when used sensibly).
 

The same applies to C's c?a:b operator: only one of a or b is evaluated, not both.

 You are conflating several ideas, then you wrote something that you /know/ is pure FUD about C's switch statements.

It wasn't. YOU wrote FUD when you called them straightforward. I would bet you that the majority of C programmers don't know just how weird switch is.

So writing "The same applies" makes no sense.

'The same applies' was in reference to this previous remark of mine:
"In general, an if-else-if chain (which was the point of the OP), would evaluate only one branch. So would a switch-case construct if sensibly implemented (in C's version, anything goes). "

You are, of course, correct that in "c ? a : b", "c" is evaluated first and then one and only one of "a" and "b".

And here you confirm that it does in fact apply: only one branch is executed.
You can't apply it to C's switch as there is no rigorous way of even determining what is a branch. Maybe it is a span between 2 case labels? But then, one of those might be in a different nested statement!

>
(This also why implementing if, switch, ?: via functions, which lots are keen to do in the reddit PL forum, requires closures, lazy evaluation or other advanced features.)
>

 Yes, you'd need something like that to implement such "short-circuit" operators using functions in C.  In other languages, things may be different.

Yes, short-circut operators would need the same features. That's why it's easier to build this stuff into a core language than to try and design a language where 90% of the features are there to implement what should be core features.

But it becomes mandatory if the whole thing returns a value, to satisfy the type system, because otherwise it will try and match with 'void'.
>

 Your language, your choice.

These things tend to come about because that is the natural order that comes through. It's something I observed rather than decided.

  I'd question the whole idea of having a construct that can evaluate to something of different types in the first place, whether or not it returns a value, but that's your choice.

If the result of a multi-way execution doesn't yield a value to be used, then the types don't matter.
If it does, then they DO matter, as they have to be compatible types in a static language.
This is just common sense; I don't know why you're questioning it. (I'd quite like to see a language of your design!)

SOMETHING needs to happen when none of the branches are executed; what value would be returned then? The behaviour needs to be defined. You don't want to rely on compiler analysis for this stuff.

 In my hypothetical language described above, it never happens that none of the branches are executed.
 Do you feel you need to write code like this?
 const char * flag_to_text_A(bool b) {
     if (b == true) {
         return "It's true!";
     } else if (b == false) {
         return "It's false!";
     } else {
         return "Schrödinger's cat has escaped!";
     }
}

 When you have your "else" or "default" clause that is added for something that can't ever happen, how do you test it?

I write code like this:
    func F(b) =
       if X then
           A                # 'return' is optional
       elsif Y then
           B
       fi
    end
As it is, it requires 'else' (because this is a value-returning function.
X Y A B are arbitrary expressions. The need for 'else' is determined during type analysis. Whether it will ever execute the default path would be up to extra analysis, that I don't do, and would anyway be done later.
You can't design a language like this where valid syntax depends on compiler and what it might or might not discover when analysing the code.
The rule instead is simple: where a multi-path construct yields a value, then it needs the default branch, always.
A compiler /might/ figure out it isn't needed, and not generate that bit of code. (Or as I suggested, it might insert a suitable branch.)
You seem to like putting the onus on compiler writers to have to analyse programs to the limit.
(Note that my example is for dynamic code; there X Y may only be known at runtime anyway.)
In my languages, the last statement of a function can be arbitrarily complex and nested; there could be dozens of points where a return value is needed.

>
In C on the other hand, the ':' of '?:' is always needed, even when it is not expected to yield a value. Hence you often see this things like this:
>
    p == NULL ? puts("error"): 0;

 Given that the tertiary operator chooses between two things, it seems fairly obvious that you need two alternatives to choose from - having a choice operator without at least two choices would be rather useless.

It seems you are just arguing in the defence of C rather than objectively, and being contradictory in the process.
For example, earlier you said I'm wrong to insist on a default path for multi-way ops when it is expected to yield a value. But here you say it is 'obvious' for the ?: multi-way operator to insist on a default path even when any value is not used.
This is on top of saying that I'm spreading 'FUD' about switch and that is it really a perfectly straightforward feature!
Now *I* am wary of trusting your judgement.

I can't say I have ever seen the tertiary operator used like this. There are a few C programmers that like to code with everything as expressions, using commas instead of semicolons, but they are IMHO mostly just being smart-arses.  It's a lot more common to write :
      if (!p) puts("error");

Well, it happens, and I've seen it (and I've had to ensure my C compiler deals with it when it comes up, which it has). Maybe some instances of it are hidden behind macros.

Meanwhile I allow this (if I was keen on a compact form):
>
   (p = nil | print "error")
>
No else is needed.
>

 In C you could write :
      p == NULL || puts("error");
 which is exactly the same structure.

This is new to me. So this is another possibility for the OP?
It's an untidy feature however; it's abusing || in similar ways to those who separate things with commas to avoid needing a compounds statement.
It is also error prone as it is untuitive: you probably meant one of:
       p != NULL || puts("error");
       p == NULL && puts("error");
There are also limitations: what follows || or || needs to be something that returns a type that can be coerced to an 'int' type.
(Note that the '|' is my example is not 'or'; it means 'then':
    (  c |    a )          # these are exactly equivalent
    if c then a fi
    (  c |    a |    )     # so are these
    if c then a else b fi
There is no restriction on what a and b are, statements or expressions, unless the whole returns some value.)

I think all of these, including your construct in your language, are smart-arse choices compared to a simple "if" statement, but personal styles and preferences vary.

C's if statement is rather limited. As it is only if-else, then if-else-if sequences must be emulated using nested if-else-(if else (if else....
Misleading indentation needs to be used to stop nested if's disappearing to the right. When coding style mandates braces around if branches, an exception needs to be made for if-else-if chains (otherwise you will end up with }}}}}}}... at the end.
And the whole thing cannot return a value; a separate ?: feature (whose branches must be expressions) is needed.
It is also liable to 'dangling' else, and error prone due to braces being optional.
It's a mess. By contrast, my if statements look like this:
    if then elsif then ... [else] fi
'elsif' is a part of the syntax. The whole thing can return a value. There is a compact form (not for elsif, that would be too much) as shown above.