Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou 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: References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org> <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> <20241105173408.11@kylheku.com> <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 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