Re: else ladders practice

On 10/11/2024 06:00, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

I assume that you consider the simple solution the 'bad' one?

 You wrote about _always_ requiring 'else' regardless if it is
needed or not.  Yes, I consider this bad.

It is 'needed' by the language because of its rules. It might not be needed by a particular function because the author knows that all expected values of the 2**64 range of most scalar parameters have been covered.
The language doesn't know.
But the rule only applies to value-returning statements; you can choose not to use such statements, but more conventional ones like those in C.
However, the language will still consider the last statement of a value-returning function to be such a statement. So either that one needs 'else' (perhaps in multiple branches), or you instead need a dummy 'return x' at the end of the function, one which is never executed.
I don't think that's too onerous, and it is safer than somehow asking the language to disable the requirement. (How would that be done, by some special keyword? Then you'd just be writing that keyword instead of 'return'!)

 

I'd would consider a much elaborate one putting the onus on external
tools, and still having an unpredictable result to be the poor of the two.
>
You want to create a language that is easily compilable, no matter how
complex the input.

 Normally time spent _using_ compiler should be bigger than time
spending writing compiler.  If compiler gets enough use, it
justifies some complexity.

That doesn't add up: the more the compiler gets used, the slower it should get?!
The sort of analysis you're implying I don't think belongs in the kind of compiler I prefer. Even if it did, it would be later on in the process than the point where the above restriction is checked, so wouldn't exist in one of my compilers anyway.
I don't like open-ended tasks like this where compilation time could end up being anything. If you need to keep recompiling the same module, then you don't want to repeat that work each time.

I am mainly concerned with clarity and correctness of source code.

So am I. I try to keep my syntax clean and uncluttered.

Dummy 'else' doing something may hide errors.

So can 'unreachable'.

Dummy 'else' signaling
error means that something which could be compile time error is
only detected at runtime.
 Compiler that detects most errors of this sort is IMO better than
compiler which makes no effort to detect them.  And clearly, once
problem is formulated in sufficiently general way, it becomes
unsolvable.  So I do not expect general solution, but expect
resonable effort.

So how would David Brown's example work:
   int F(int n) {
      if (n==1) return 10;
      if (n==2) return 20;
   }
/You/ know that values -2**31 to 0 and 3 to 2**31-1 are impossible; the compiler doesn't. It's likely to tell you that you may run into the end of the function.
So what do you want the compiler to here? If I try it:
   func F(int n)int =
       if n=1 then return 10 fi
       if n=2 then return 20 fi
   end
It says 'else needed' (in that last statement). I can also shut it up like this:
   func F(int n)int =                      # int is i64 here
       if n=1 then return 10 fi
       if n=2 then return 20 fi
       0
   end
Since now that last statement is the '0' value (any int value wil do). What should my compiler report instead? What analysis should it be doing? What would that save me from typing?

normally you do not need very complex analysis:

>
I don't want to do any analysis at all! I just want a mechanical
translation as effortlessly as possible.
>
I don't like unbalanced code within a function because it's wrong and
can cause problems.

 Well, I demand more from compiler than you do...

Perhaps you're happy for it to be bigger and slower too. Most of my projects build more or less instantly. Here 'ms' is a version that runs programs directly from source (the first 'ms' is 'ms.exe' and subsequent ones are 'ms.m' the lead module):
  c:\bx>ms ms ms ms ms ms ms ms ms ms ms ms ms ms ms ms hello
  Hello World! 21:00:45
This builds and runs 15 successive generations of itself in memory before building and running hello.m; it took 1 second in all. (Now try that with gcc!)
Here:
   c:\cx>tm \bx\mm -runp cc sql
   Compiling cc.m to <pcl>
   Compiling sql.c to sql.exe
This compiles my C compiler from source but then it /interprets/ the IR produced. This interpreted compiler took 6 seconds to build the 250Kloc test file, and it's a very slow interpreter (it's used for testing and debugging).
(gcc -O0 took a bit longer to build sql.c! About 7 seconds but it is using a heftier windows.h.)
If I run the C compiler from source as native code (\bx\ms cc sql) then building the compiler *and* sql.c takes 1/3 of a second.
You can't do this stuff with the compilers David Brown uses; I'm guessing you can't do it with your prefered ones either.