Re: else ladders practice

On 03/11/2024 17:00, David Brown wrote:

On 02/11/2024 21:44, Bart wrote:

I would disagree on that definition, yes.  A "multi-way selection" would mean, to me, a selection of one of N possible things - nothing more than that.  It is far too general a phrase to say that it must involve branching of some sort ("notional" or otherwise).

Not really. If the possible options involving actions written in-line, and you only want one of those executed, then you need to branch around the others!

  And it is too general to say if you are selecting one of many things to do, or doing many things and selecting one.

Sorry, but this is the key part. You are not evaluating N things and selecting one; you are evaluating ONLY one of N things.
The former is more like construction a list, the latter is multi-way select. It's illustrated with this bit of scripting code:
   x := ( printf("one"), printf("two"), printf("three"))[3]
   println
   println =x
   y := (3 | printf("one"), printf("two"), printf("three") | printf("default"))
   println
   println =y
The output is:
   onetwothree
   X= 5
   three
   Y= 5
For X, it builds a list by evaluating all the elements, and returns the value of the last. For Y, it evaluates only ONE element (using internal switch, so branching), which again is the last.
You don't seem keen on keeping these concepts distinct?
Well, C has EXACTLY those same concepts, and I can come up with similar examples in C (I may even have posted some), for example using compound literal for the first, and a regular if-else or nested ?: chain for the second. (But only ?: can return that '5'.)

>
The whole construct may or may not return a value. If it does, then one of the N paths must be a default path.
>

 No, that is simply incorrect.  For one thing, you can say that it is perfectly fine for the selection construct to return a value sometimes and not at other times.

How on earth is that going to satisfy the type system? You're saying it's OK to have this:
    int x = if (randomfloat()<0.5) 42;
Or even this, which was discussed recently, and which is apparently valid C:
    int F(void) {
        if (randomfloat()<0.5) return 42;
In the first example, you could claim that no assignment takes place with a false condition (so x contains garbage). In the second example, what value does F return when the condition is false?
You can't hide behind your vast hyper-optimising compiler; the language needs to say something about it.
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.
After all, this is C! But please tell me, what would be the downside of not allowing it?
   It's fine if it never returns at all for some

cases.  It's fine to give selection choices for all possible inputs. It's fine to say that the input must be a value for which there is a choice.
 What I see here is that you don't like C's constructs (that may be for good reasons, it may be from your many misunderstandings about C, or it may be from your knee-jerk dislike of everything C related).

With justification. 0010 means 8 in C? Jesus.
It's hardly knee-jerk either since I first looked at it in 1982, when my own language barely existed. My opinion has not improved.
(I remarked elsewhere that C is like the Trump of programming languages; there is no amount of crassness that will turn people off it!)

  You have some different selection constructs in your own language, which you /do/ like.  (It would be very strange for you to have constructs that you don't like in your own personal one-man language.)

It's a one-man language but most of its constructs and features are universal. And therefore can be used for comparison.

One feature of my concept of 'multi-way select' is that there is one or more controlling expressions which determine which path is followed.
>

 Okay, that's fine for /your/ language's multi-way select construct.  But other people and other languages may do things differently.

FGS, /how/ different? To select WHICH path or which element requires some input. That's the controlling expression.
Or maybe with your ideal language, you can select an element of an array without bothering to provide an index!

There are plenty of C programmers - including me - who would have preferred to have "switch" be a more structured construct which could not be intertwined with other constructs in this way.  That does not mean "switch" is not clearly defined - nor does it hinder almost every real-world use of "switch" from being reasonably clear and structured. It does, however, /allow/ people to use "switch" in more complex and less clear ways.

Try and write a program which takes any arbitrary switch construct (that usually means written by someone else, because obviously all yours will be sensible), and cleanly isolates all the branches including the default branch.
Hint: the lack of 'break' in a non-empty span between two case labels will blur the line. So will a conditional break (example below unless it's been culled).

You are confusing "this makes it possible to write messy code" with a belief that messy code is inevitable or required.  And you are forgetting that it is always possible to write messy or incomprehensible code in any language, with any construct.

I can't write that randomfloat example in my language. I can't leave out a 'break' in a switch statement (it's not meaningful). It is impossible to do the crazy things you can do with switch in C.
Yes, with most languages you can write nonsense programs, but that doesn't give the language a licence to forget basic rules and common sense, and just allow any old rubbish even if clearly wrong:
    int F() {
        F(1, 2.3, "four", F,F,F,F(),F(F()));
        F(42);
    }
This is apparently valid C. It is impossible to write this in my language.

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.
>

 It is simple and obvious to enumerate the branches in almost all real-world cases of switch statements.  (And /please/ don't faff around with cherry-picked examples you have found somewhere as if they were representative of anything.)

Oh, right. I'm not allowed to use counter-examples to lend weight to my comments. In that case, perhaps you shouldn't be allowed to use your sensible examples either. After all we don't know what someone will feed to a compiler.
But, suppose C was upgraded so that switch could return a value. For that, you'd need the value at the end of each branch. OK, here's a simple one:
     y = switch (x) {
         case 12:
             if (c) case 14: break;
             100;
         case 13:
             200;
             break;
         }
Any ideas? I will guess that x=12/c=false or c=13 will yield 200. What avout x=12/c=true, or x=14, or x = anything else?

So if I understand correctly, you are saying that chains of if/else, an imaginary version of "switch", and the C tertiary operator all evaluate the same things in the same way, while with C's switch you have no idea what happens?

Yes. With C's switch, you can't /in-general/ isolate things into distinct blocks. You might have a stab if you stick to a subset of C and follow various guidelines, in an effort to make 'switch' look normal.
See the example above.

  That is true, if you cherry-pick what you choose to ignore in each case until it fits your pre-conceived ideas.

You're the one who's cherry-picking examples of C! Here is my attempt at converting the above switch into my syntax (using a tool derived from my C compiler):
     switch x
     when 12 then
         if c then
         fi
         100
         fallthrough
     when 13 then
         200
     end switch
It doesn't attempt to deal with fallthrough, and misses out that 14-case, and that conditional break. It's not easy; I might have better luck with assembly!

No, what you call "natural" is entirely subjective.  You have looked at a microscopic fraction of code written in a tiny proportion of programming languages within a very narrow set of programming fields.

I've worked with systems programming and have done A LOT in the 15 years until the mid 90s. That included pretty much everything involved in writing graphical applications given only a text-based disk OS that provided file-handling.
Plus of course devising and implementing everthing needed to run my own systems language. (After mid 90s, Windows took over half the work.)

That's not criticism - few people have looked at anything more.

Very few people use their own languages, especially over such a long period, also use them to write commercial applications, or create languages for others to use.

  What I /do/ criticise is that your assumption that this almost negligible experience gives you the right to decide what is "natural" or "true", or how programming languages or tools "should" work.

So, in your opinion, 'switch' should work how it works in C? That is the most intuitive and natural way implementing it?

  You need to learn that other people have different ideas, needs, opinions or preferences.

Most people haven't got a clue about devising PLs.

  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.
>

 Of course they do.

Of course they don't! Here, F, G and H return int, float and void* respectively:
         if (c1) F();
    else if (c2) G();
    else         H();
C will not complain that those branches yield different types. But you say it should do? Why?
You're just being contradictory for the sake of it aren't you?!

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!)

 def foo(n) :
     if n == 1 : return 10
     if n == 2 : return 20
     if n == 3 : return
 That's Python, quite happily having a multiple choice selection that sometimes does not return a value.

Python /always/ returns some value. If one isn't provided, it returns None. Which means checking that a function returns an explicit value goes out the window. Delete the 10 and 20 (or the entire body), and it still 'works'.

  Yes, that is a dynamically typed language, not a statically type language.
 std::optional<int> foo(int n) {
     if (n == 1) return 10;
     if (n == 2) return 20;
     if (n == 3) return {};
}
 That's C++, a statically typed language, with a multiple choice selection that sometimes does not return a value - the return type supports values of type "int" and non-values.

So what happens when n is 4? Does it return garbage (so that's bad). Does it arrange to return some special value of 'optional' that means no value? In that case, the type still does matter, but the language is providing that default path for you.

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.
>

 But if it is not possible for neither of X or Y to be true, then how would you test the "else" clause?  Surely you are not proposing that programmers be required to write lines of code that will never be executed and cannot be tested?

Why not? They still have to write 'end', or do you propose that can be left out if control never reaches the end of the function?!
(In earlier versions of my dynamic language, the compiler would insert an 'else' branch if one was needed, returning 'void'.
I decided that requiring an explicit 'else' branch was better and more failsafe.)

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.
>

 Why not?  It is entirely reasonable to say that a compiler for a language has to be able to do certain types of analysis.

This was the first part of your example:
  const char * flag_to_text_A(bool b) {
     if (b == true) {
         return "It's true!";
     } else if (b == false) {
         return "It's false!";
/I/ would question why you'd want to make the second branch conditional in the first place. Write an 'else' there, and the issue doesn't arise.
Because I can't see the point of deliberately writing code that usually takes two paths, when either:
  (1) you know that one will never be taken, or
  (2) you're not sure, but don't make any provision in case it is
Fix that first rather relying on compiler writers to take care of your badly written code.
And also, you keep belittling my abilities and my language, when C allows:
   int F(void) {}
How about getting your house in order first.

Anyone who is convinced that their own personal preferences are more "natural" or inherently superior to all other alternatives, and can't justify their claims other than saying that everything else is "a mess", is just navel-gazing.

I wrote more here but the post is already too long. Let's just that 'messy' is a fair assessment of C's conditional features, since you can write this:
    if (c1) {
       if (c2) s1;
    else if (c3)
       s2;
    }
What does it even mean?
The decisions *I* made resulted in a better syntax with fewer ways to inadvertently get things wrong or writing ambiguous code. You for some reason call that navel-gazing.