Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko Newsgroups: comp.lang.c Subject: Re: Interval Comparisons Date: Tue, 4 Jun 2024 16:11:28 +0300 Organization: - Lines: 74 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 04 Jun 2024 15:11:28 +0200 (CEST) Injection-Info: dont-email.me; posting-host="cbc14f7bebf39ba24d6486f0c1f0799c"; logging-data="477420"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+EPWCrkX4Yz75nz69kiBX9" User-Agent: Unison/2.2 Cancel-Lock: sha1:YoDi033bpHLVjA/42TILIx6ydYE= Bytes: 3857 On 2024-06-04 11:02:03 +0000, David Brown said: > On 04/06/2024 11:13, Mikko wrote: >> On 2024-06-04 08:58:53 +0000, David Brown said: >> >>> On 04/06/2024 09:14, Lawrence D'Oliveiro wrote: >>>> Would it break backward compatibility for C to add a feature like this >>>> from Python? Namely, the ability to check if a value lies in an interval: >>>> >>>> def valid_char(c) : >>>> "is integer c the code for a valid Unicode character." \ >>>> " This excludes surrogates." >>>> return \ >>>> ( >>>> 0 <= c <= 0x10FFFF >>>> and >>>> not (0xD800 <= c < 0xE000) >>>> ) >>>> #end valid_char >>> >>> Do you mean, could C treat "a <= x <= b" as "(a <= x) && (x <= b)" >>> without breaking existing code?  The answer is no, C treats it as the >>> expression "(a <= x) <= b".  So you would be changing the meaning of >>> existing C code.  I think it's fair to say there is likely to be very >>> little existing correct and working C code that relies on the current >>> interpretation of such expressions, but the possibility is enough to >>> rule out such a change ever happening in C.  (And it would also >>> complicate the grammar a fair bit.) >>> >>> >>> >> >> That does not prevet from doing the same with a different syntax. >> The main difference is that in the current C syntax that cannot be >> said without mentioning c twice. In the example program C would >> require that c is mentioned four times but the shown Python code >> only needs it mentioned twice. An ideal syntax woult only mention >> it once, perhaps >> >>  return c in 0 .. 0xD7FF, 0xE000 .. 0x10FFFF ; >> >> or >> >>  return c : [0 .. 0xD800), [0xE000 .. 0x10FFFF] ; >> >> or something like that, preferably so that no new reserved word is >> needed. >> > > Sure, you can always add new things to a language if they would > previously have been syntax errors or constraint errors. But is there > a use for it? I don't see any need. That c must be mentioned twice for each interval is not a problem. If there is a complex expression in place of c it can be computed and stored to a variable before comparison to an interval. > It is fine if you have a language that has good support for lists, > sets, ranges, and other higher-level features - then an "in" keyword is > a great idea. But C is not such a language, and that kind of feature > would be well outside the scope of the language. Or, if one for some reason does it in C anyway, one should have or make a library of the essential functions, incuding membership tests. > It would be easy enough to write a macro "in_range(a, x, b)" that would > do the job. It is even easier, and more productive, that you simply > write the "valid_char" function and use it, if that's what you need. Indeed. -- Mikko