Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 3 Nov 2024 18:00:51 +0100
Organization: A noiseless patient Spider
Lines: 659
Message-ID: <vg8a84$euka$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg0t3j$2ruor$1@dont-email.me>
 <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <vg2llt$38ons$1@dont-email.me>
 <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 03 Nov 2024 18:00:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="84a3be8bf174386b8eaf0d2ab83f5d33";
	logging-data="490122"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zeDJL8ivz40/9SusloejbHjCrMoFkjSA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:i9e3ODRFrueuTWkQ+kAwt90jVi0=
Content-Language: en-GB
In-Reply-To: <vg62vg$3uv02$1@dont-email.me>
Bytes: 28382

On 02/11/2024 21:44, Bart wrote:
> On 02/11/2024 11:41, David Brown wrote:
>> On 01/11/2024 20:47, Bart wrote:
>>> On 01/11/2024 18:47, David Brown wrote:
>>>> On 01/11/2024 19:05, Bart wrote:
>>>>> On 01/11/2024 17:35, David Brown wrote:
>>>
>>>>>>
>>>>>> What you have written here is all correct, but a more common 
>>>>>> method would be to avoid having three printf's :
>>>>>>
>>>>>> void shout_a_number(int n) {
>>>>>>      printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>>>>>> }
>>>>>>
>>>>>> That's more likely to match what people would want.
>>>>>
>>>>> I was also trying to show that all elements are evaluated, so each 
>>>>> has to have some side-effect to illustrate that.
>>>>
>>>> Fair enough.
>>>>
>>>>>
>>>>> A true N-way-select construct (C only really has ?:) would evaluate 
>>>>> only one, and would deal with an out-of-range condition.
>>>>
>>>> That's a matter of opinion and design choice, rather than being 
>>>> requirements for a "true" select construct.
>>>
>>> I don't think it's just opinion.
>>
>> Yes, it is.
> 
> 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.

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).  And it is too general 
to say if you are selecting one of many things to do, or doing many 
things and selecting one.

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

And then you are leaping from "I like things this way" to "Everyone 
likes them this way", "This way is the only correct way", "This is the 
true definition", and "Other ways are clearly wrong".

> 
>> I don't disagree that such an "select one of these and evaluate only 
>> that" construct can be a useful thing, or a perfectly good alternative 
>> to to an "evaluate all of these then select one of them" construct.  
>> But you are completely wrong to think that one of these two is somehow 
>> the "true" or only correct way to have a selection.
>>
>> In some languages, the construct for "A or B" will evaluate both, then 
>> "or" them.  In other languages, it will evaluate "A" then only 
>> evaluate "B" if necessary.  In others, expressions "A" and "B" cannot 
>> have side-effects, so the evaluation or not makes no difference.  All 
>> of these are perfectly valid design choices for a language.
> 
> Those logical operators that may or may not short-circuit.
> 

Usually a language definition will be explicit about whether or not they 
short-circuit.  Some may be vaguer, then it is only safe to use the 
constructs when there are no side-effects involved.  (Languages which do 
not allow side-effects, such as pure functional programming languages, 
may be intentionally vague.)

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

> So, I'd be interested in what you think of as a multi-way select which 
> may evaluate more than one branch. Or was it that 'or' example?
> 

The examples you started with in C - creating an array, then picking one 
of them - is a perfectly good multi-way selection construct which 
evaluates all the options and then picks the result of one of them.

> 
>>>
>>> In general, an if-else-if chain (which was the point of the OP), 
>>> would evaluate only one branch.
>>
>> It evaluates all the conditionals down the chain until it hits a 
>> "true" result, then evaluates the body of the "if" that matches, then 
>> skips the rest.
> 
> I don't count evaluating the conditionals: here it is the branches that 
> count (since it is one of those that is 'selected' via those 
> conditionals), and here you admit that only one is executed.
> 

That seems an arbitrary choice - the controlling expressions for the 
conditionals also need to be evaluated.

And "admit" is a strange choice of words - are you trying to make it 
sound like you have convinced me of something, or forced a concession of 
some sort?  I have merely being describing how C works here - this is a 
matter of fact, not opinion or knowledge.  We can all have opinions on 
whether we like way C does things - and we may be persuaded to change 
those opinions.  But the reality of how C works is not up for debate.

>> (Of course generated code can evaluate all sorts of things in 
>> different orders, as long as observable behaviour - side-effects - are 
>> correct.)
>>
>>> So would a switch-case construct if sensibly implemented (in C's 
>>> version, anything goes).
>>>
>>
>> C's switch is perfectly simply and clearly defined.  It is not 
>> "anything goes".  The argument to the switch is evaluated once, then 
>> control jumps to the label of the switch case, then evaluation 
>> continues from that point.  It is totally straight-forward.
> 
> It's pretty much the complete opposite of straightforward, as you go on 
> to demonstrate.

I described it in a single sentence.  Though I skipped some details, it 
covered enough for almost all real-world uses of "switch".

> 
> C 'switch' looks like it might be properly structured if written 
> sensibly. The reality is different: what follows `switch (x)` is just 
> ONE C statement, often a compound statement.

Grammatically it is one statement, but invariably that one statement is 
a compound statement.

> 
> Case labels can located ANYWHERE within that statement, including within 
> nested statements (eg. inside a for-statement), and including 
> 'default:', which could go before all the case labels!

Yes - the programmer has a responsibility to write sensible code.

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.

> 
========== REMAINDER OF ARTICLE TRUNCATED ==========