Sujet : Re: else ladders practice
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 10. Nov 2024, 05:01:44
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vgpb7a$7eak$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
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