Re: else ladders practice

David Brown <david.brown@hesbynett.no> wrote:

On 05/11/2024 20:39, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 05/11/2024 13: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.

>
I appreciate this is what Bart means by that phrase, but I don't agree
with it.  I'm not sure if that is covered by "OK" or not!

 
You may prefer your own definition, but Bart's is resonable one.

 
The only argument I can make here is that I have not seen "multi-way
select" as a defined phrase with a particular established meaning.

There is well-defined concept appearing when studing control structures.
I am not sure if "multi-way select" is usual name for it, but with
Bart explanation it is very clear that he meant this concept.  And
even without his explanation I would assume that he meant this concept.

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

>
I think this is all very dependent on what you mean by "all input values".
>
Supposing I declare this function:
>
// Return the integer square root of numbers between 0 and 10
int small_int_sqrt(int x);
>
>
To me, the range of "all input values" is integers from 0 to 10.  I
could implement it as :
>
int small_int_sqrt(int x) {
        if (x == 0) return 0;
        if (x < 4) return 1;
        if (x < 9) return 2;
        if (x < 16) return 3;
        unreachable();
}
>
If the user asks for small_int_sqrt(-10) or small_int_sqrt(20), that's
/their/ fault and /their/ problem.  I said nothing about what would
happen in those cases.
>
But some people seem to feel that "all input values" means every
possible value of the input types, and thus that a function like this
should return a value even when there is no correct value in and no
correct value out.

 
Well, some languages treat types more seriously than C.  In Pascal
type of your input would be 0..10 and all input values would be
handled.  Sure, when domain is too complicated to express in type
than it could be documented restriction.  Still, it makes sense to
signal error if value goes outside handled rage, so in a sense all
values of input type are handled: either you get valid answer or
clear error.

 
No, it does not make sense to do that.  Just because the C language does
not currently (maybe once C++ gets contracts, C will copy them) have a
way to specify input sets other than by types, does not mean that
functions in C always have a domain matching all possible combinations
of bits in the underlying representation of the parameter's types.
 
It might be a useful fault-finding aid temporarily to add error messages
for inputs that are invalid but can physically be squeezed into the
parameters.  That won't stop people making incorrect declarations of the
function and passing completely different parameter types to it, or
finding other ways to break the requirements of the function.
 
And in general there is no way to check the validity of the inputs - you
usually have no choice but to trust the caller.  It's only in simple
cases, like the example above, that it would be feasible at all.
 
 
There are, of course, situations where the person calling the function
is likely to be incompetent, malicious, or both, and where there can be
serious consequences for what you might prefer to consider as invalid
input values.

You apparently exclude possibility of competent persons making a
mistake.  AFAIK industry statistic shows that code develeped by
good developers using rigorous process still contains substantial
number of bugs.  So, it makes sense to have as much as possible
verified mechanically.  Which in common practice means depending on
type checks.  In less common practice you may have some theorem
proving framework checking assertions about input arguments,
then the assertions take role of types.

You have that for things like OS system calls - it's no
different than dealing with user inputs or data from external sources.
But you handle that by extending the function - increase the range of
valid inputs and appropriate outputs.  You no longer have a function
that takes a number between 0 and 10 and returns the integer square root
- you now have a function that takes a number between -(2 ^ 31 + 1) and
(2 ^ 31) and returns the integer square root if the input is in the
range 0 to 10 or halts the program with an error message for other
inputs in the wider range.  It's a different function, with a wider set
of inputs - and again, it is specified to give particular results for
particular inputs.

It make sense to extend definition when such extention converts
function which use can be verified only by informal process into
one with formally verified use.

I certainly would
be quite unhappy with code above.  It is possible that I would still
use it as a compromise (say if it was desirable to have single
prototype but handle points in spaces of various dimensions),
but my first attempt would be something like:
 
typedef struct {int p[2];} two_int;
....
 

 
I think you'd quickly find that limiting and awkward in C (but it might
be appropriate in other languages).

Your snippet handled only two element arrays.  If that is right assumption
for the problem, then typedef above expresses it in IMO resonable
way.  Yes, it is more characters to write than usual C idioms.
My main "trouble" is that usually I want to handle variable sized
arrays.  In such case beside pointer there would be size argument.
I would probably use variably modified type in such case.

But don't misunderstand me - I am
all in favour of finding ways in code that make input requirements
clearer or enforceable within the language - never put anything in
comments if you can do it in code.  You could reasonably do this in C
for the first example :
 
 
// Do not use this directly
extern int small_int_sqrt_implementation(int x);
 
 
// Return the integer square root of numbers between 0 and 10
static inline int small_int_sqrt(int x) {
       assert(x >= 0 && x <= 10);
       return small_int_sqrt_implementation(x);
}

Hmm, why extern implementation and static wrapper?  I would do
the opposite.

A function should accept all input values - once you have made clear
what the acceptable input values can be.  A "default" case is just a
short-cut for conveniently handling a wide range of valid input values -
it is never a tool for handling /invalid/ input values.

 
Well, default can signal error which frequently is right handling
of invalid input values.
 

 
Will that somehow fix the bug in the code that calls the function?
 
It can be a useful debugging and testing aid, certainly, but it does not
make the code "correct" or "safe" in any sense.

There is concept of "partial correctness": code if it finishes returns
correct value.  A variation of this is: code if it finishes without
signaling error returns correct values.  Such condition may be
much easier to verify than "full correctness" and in many case
is almost as useful.  In particular, mathematicians are _very_
unhappy when program return incorrect results.  But they are used
to programs which can not deliver results, either because of
lack or resources or because needed case was not implemented.

When dealing with math formulas there are frequently various
restrictions on parameters, like we can only divide by nonzero
quantity.  By signaling error when restrictions are not
satisfied we ensure that sucessful completition means that
restrictions were satisfied.  Of course that alone does not
mean that result is correct, but correctness of "general"
case is usually _much_ easier to ensure.  In other words,
failing restrictions are major source of errors, and signaling
errors effectively eliminates it.

In world of prefect programmers, they would check restrictions
before calling any function depending on them, or prove that
restrictions on arguments to a function imply correctness of
calls made by the function.  But world is imperfect and in
real world extra runtime checks are quite useful.

--
                              Waldek Hebisch