Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 10 Nov 2024 05:01:44 +0100
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <vgpb7a$7eak$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <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> <vgd3ro$2pvl4$1@paganini.bofh.team>
 <vgd6jh$1hmjc$1@dont-email.me> <vgds97$2r682$1@paganini.bofh.team>
 <vgdvfj$1m6ho$1@dont-email.me> <vge84o$1o57r$2@dont-email.me>
 <20241105173408.11@kylheku.com> <vgfepe$22j2u$1@dont-email.me>
 <672F3485.6090805@grunge.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 10 Nov 2024 05:01:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8b36ee32fc6a9c2268dd752f714c9232";
	logging-data="244052"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18WPRarnOm6pj5pXSX88DQv"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:OmuXAUGHefR0/ayPXJF2TMnL+kQ=
In-Reply-To: <672F3485.6090805@grunge.pl>
X-Enigmail-Draft-Status: N1110
Bytes: 3901

On 09.11.2024 11:08, fir wrote:
> Bart wrote:
>> On 06/11/2024 07:26, Kaz Kylheku wrote:
>>> On 2024-11-05, Bart <bc@freeuk.com> wrote:
>>
>>>> [...]  I extended the latter to N-way select:
>>>>
>>>>      x := (n | a, b, c, ... | z)
>>>
>>> This looks quite error-prone. You have to count carefully that
>>> the cases match the intended values. If an entry is
>>> inserted, all the remaining ones shift to a higher value.
>>>
>>> You've basically taken a case construct and auto-generated
>>> the labels starting from 1.
>>
>> It's a version of Algol68's case construct:
>>
>>     x := CASE n IN a, b, c OUT z ESAC
>>
>> which also has the same compact form I use. I only use the compact
>> version because n is usually small, and it is intended to be used within
>> an expression: print (n | "One", "Two", "Three" | "Other").
>>
>> [...]
>>
>> An out-of-bounds index yields 'void' (via a '| void' part inserted by
>> the compiler). This is one of my examples from that era:
>>
>>    xt := (messa | 1,1,1, 2,2,2, 3,3,3)
>>    yt := (messa | 3,2,1, 3,2,1, 3,2,1)
>>
> 
> still the more c compatimle version would look better imo
> 
>     xt =  {1,1,1, 2,2,2, 3,3,3}[messa];
>     yt =  {3,2,1, 3,2,1, 3,2,1}[messa];
> 
> [...]

It might look better - which of course lies in the eyes of the
beholder - but this would actually need more guaranteed context
or explicit tests (whether "messa" is within defined bounds) to
become a safe construct; which then again makes it more clumsy.

Above you also write about the syntax (which included the 'else'
case) that "This looks quite error-prone." and that you have to
"count carefully". Why do you think the "C-like" syntax is less
error prone and that you wouldn't have to count?

The biggest problem with such old switch semantics is, IMO, that
you have to map them on sequence numbers [1..N], or use them just
in contexts where you naturally have such selectors given. (Not
that the "C-like" suggestion would address that inherent issue.)

In "C" I occasionally used a  {...}[...]  or  "..."[...]  syntax,
but rather in this form:  {...}[... % n] , where 'n' is the
determined (constant) number of elements.

Janis