Re: else ladders practice

Bart <bc@freeuk.com> wrote:

On 05/11/2024 19:53, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

On 05/11/2024 12:42, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

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

>
OK.
  

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

>
>
You need to cover all input values.  This is possible when there
is reasonably small number of possibilities.  For example, switch on
char variable which covers all possible values does not need default
path.  Default is needed only when number of possibilities is too
large to explicitely give all of them.  And some languages allow
ranges, so that you may be able to cover all values with small
number of ranges.
>

>
What's easier to implement in a language: to have a conditional need for
an 'else' branch, which is dependent on the compiler performing some
arbitrarily complex levels of analysis on some arbitrarily complex set
of expressions...
>
...or to just always require 'else', with a dummy value if necessary?

 
Well, frequently it is easier to do bad job, than a good one.

 
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.
 

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.

With the simple solution, the worst that can happen is that you have to
write a dummy 'else' branch, perhaps with a dummy zero value.
 
If control never reaches that point, it will never be executed (at
worse, it may need to skip an instruction).
 
But if the compiler is clever enough (optionally clever, it is not a
requirement!), then it could eliminate that code.
 
A bonus is that when debugging, you can comment out all or part of the
previous lines, but the 'else' now catches those untested cases.

I am mainly concerned with clarity and correctness of source code.
Dummy 'else' doing something may hide errors.  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.

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

--
                              Waldek Hebisch