Deutsch English Français Italiano |
<v3mtf2$ct28$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: bart <bc@freeuk.com> Newsgroups: comp.lang.c Subject: Re: Interval Comparisons Date: Tue, 4 Jun 2024 12:23:15 +0100 Organization: A noiseless patient Spider Lines: 95 Message-ID: <v3mtf2$ct28$2@dont-email.me> References: <v3merq$b1uj$1@dont-email.me> <v3ml0d$bpds$5@dont-email.me> <v3mlrb$c7d5$1@dont-email.me> <v3ms7b$d5sq$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 04 Jun 2024 13:23:15 +0200 (CEST) Injection-Info: dont-email.me; posting-host="027492d54fa7a72a30fd705d730c9473"; logging-data="422984"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MQjquCWRAEw1iKr/bmrv/" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:uI8//FtxNuYuDErYME6kvPLQDxY= Content-Language: en-GB In-Reply-To: <v3ms7b$d5sq$1@dont-email.me> Bytes: 4645 On 04/06/2024 12:02, David Brown wrote: > 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.) >>> >>> >>> <https://c-faq.com/expr/transitivity.html> >> >> 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? > > 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. I disagree. I have a script language where 'in' works with all sorts of data types, and where ranges like a..b and sets like [a..b, c, d, e] are actual types. Yet I also introduced 'in' into my systems language, even though it is very restricted: if a in b..c then if a in [b, c, d] then This is limited to integer types. The set construct here doesn't allow ranges (it could have done). Neither the range or set is a datatype - it just syntax. (I can't do range r := 1..10.) It is incredibly useful: if c in [' ', '\t', '\n'] then ... # whitespace if b in 0..255 then if b in u8.bounds then # alternative Not to forget: if x = y = 0 then # both x and y are zero It doesn't need the full spec of the higher level language. > 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. Yes it would be easier - to provide an ugly, half-assed solution that everyone will write a different way (I would use (x, a, b) for example), and which can go wrong as soon as someone writes (a, x(), b). That's the problem with the macro scheme, it stops the language properly evolving.