Re: else ladders practice

On 06/11/2024 15:47, David Brown wrote:

On 06/11/2024 15:40, Bart wrote:

There are irrelevant differences in syntax, which could easily disappear entirely if a language supported a default initialisation value when a return gives no explicit value.  (i.e., "T foo() { return; }; T x = foo();" could be treated in the same way as "T x;" in a static initialisation context.)

You wrote:
   T foo () {return;}        # definition?
   T x = foo();              # call?
I'm not quite sure what you're saying here. That a missing return value in non-void function would default to all-zeros?
Maybe. A rather pointless feature just to avoid writing '0', and which now introduces a new opportunity for a silent error (accidentally forgetting a return value).
It's not quite the same as a static initialisiation, which is zeroed when a program starts.

Then you list some things that may or may not happen, which are of course totally irrelevant.  If you list the differences between bikes and cars, you don't include "some cars are red" and "bikes are unlikely to be blue".

Yes; if you're using a vehicle, or planning a journey or any related thing, it helps to remember if it's a bike or a car! At least here you acknowledge the difference.
But I guess you find those likely/unlikely macros of gcc pointless too. If I know something is a procedure, then I also know it is likely to change global state, that I might need to deal with a return value, and a bunch of other stuff.
Boldly separating the two with either FUNC or PROC denotations I find helps tremendously. YM-obviously-V, but you can't have a go at me for my view.
If I really found it a waste of time, the distinction would have been dropped decades ago.

It's a pointless distinction.  Any function or procedure can be morphed into the other form without any difference in the semantic meaning of the code, requiring just a bit of re-arrangement at the caller site:
      int foo(int x) { int y = ...; return y; }
      void foo(int * res, int x) { int y = ...; *res = y; }
       void foo(int x) { ... ; return; }
      int foo(int x) { ... ; return 0; }
 

There is no relevance in the division here, which is why most languages don't make a distinction unless they do so simply for syntactic reasons.

As I said, you like to mix things up. You disagreed. I'm not surprised.
Here you've demonstrated how a function that returns results by value can be turned into a procedure that returns a result by reference.
So now, by-value and by-reference are the same thing?
I listed seven practical points of difference between functions and procedures, and above is an eighth point, but you just dismissing them. Is there any point in this?
I do like taking what some think as a single feature and having dedicated versions, because I find it helpful.
That includes functions, loops, control flow and selections.

In C, the syntax is dreadful: not only can you barely distinguish a function from a procedure (even without attributes, user types and macros add in), but you can hardly tell them apart from variable declarations.

 As always, you are trying to make your limited ideas of programming languages appear to be correct, universal, obvious or "natural" by saying things that you think are flaws in C.  That's not how a discussion works, and it is not a way to convince anyone of anything. The fact that C does not have a keyword used in the declaration or definition of a function does not in any way mean that there is the slightest point in your artificial split between "func" and "proc" functions.

   void F();
   void (*G);
   void *H();
   void (*I)();
OK, 4 things declared here. Are they procedures, functions, variables, or pointers to functions? (I avoided using a typedef in place of 'void' to make things easier.)
I /think/ they are as follows: procedure, pointer variable, function (returning void*), and pointer to a procedure. But I had to work at it, even though the examples are very simple.
I don't know about you, but I prefer syntax like this:
    proc F
    ref void G
    ref proc H
    func I -> ref void
Now come on, scream at again for prefering a nice syntax for programming, one which just tells me at a glance what it means without having to work it out.

 (It doesn't matter that I too prefer a clear keyword for defining functions in a language.)

Why? Don't your smart tools tell you all that anyway?

That is solely from your choice of an IL.

The IL design also falls into place from the natural way these things have to work.

Of course you are wrong!

You keep saying that. But then you also keep saying, from time to time, that you agree that something in C was a bad idea. So I'm still wrong when calling out the same thing?

 If there was an alternative language that I thought would be better for the tasks I have, I'd use that.  (Actually, a subset of C++ is often better, so I use that when I can.)
 What do you think I should do instead?  Whine in newsgroups to people that don't write language standards (for C or anything else) and don't make compilers?

What makes you think I'm whining? The thread opened up a discussion about multi-way selections, and it got into how it could be done with features from other languages.
I gave some examples from mine, as I'm very familiar with that, and it uses simple features that are easy to grasp and appreciate. You could have done the same from ones you know.
But you just hate the idea that I have my own language to draw on, whose syntax is very sweet ('serious' languages hate such syntax for some reason, and is usually relegated to scripting languages.)
I guess then you just have to belittle and insult me, my languages and my views at every opporunity.

Make my own personal language that is useless to everyone else and holds my customers to ransom by being the only person that can work with their code?

Plenty of companies use DSLs. But isn't that sort of what you do? That is, using 'C' with a particular interpretation or enforcement of the rules, which needs to go in hand with a particular compiler, version, sets of options and assorted makefiles.
I for one would never be able to build one of your programs. It might as well be written in your inhouse language with proprietory tools.