Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 16:11:28 +0300
Organization: -
Lines: 74
Message-ID: <v3n3q0$ei7c$1@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=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.)
>>> 
>>> 
>>> <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?

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