Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Tue, 4 Jun 2024 15:24:43 +0200
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <v3n4is$emdc$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>
 <v3mtf2$ct28$2@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 15:24:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7740955b17fd8df0cccaba227b9e3b39";
	logging-data="481708"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IQfVgfJreslTLYkxWQSM9pKp0WYssHCk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:38B1NWoArS7kbxEsA1yiA7Jwtmw=
In-Reply-To: <v3mtf2$ct28$2@dont-email.me>
Content-Language: en-GB
Bytes: 7030

On 04/06/2024 13:23, bart wrote:
> 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.

C is not a script language.

> 
> 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.)

Adding such a feature to your own personal language, for your own 
personal use, is easy enough (relative to the rest of the work involved 
in designing your own personal language and making tools for it, which 
is of course no small feat).  Adding it to C with its standards, 
existing code, toolchains, additional tools, developers, etc., is a 
whole different kettle of fish.

I don't think it would be practical to add it to C in a way that is 
simple and restricted enough to be suitable for C, while also being 
useful enough to make it worth the effort.

Remember, when you add these things to your own language, you have your 
own needs in mind and can ignore everything else, all corner cases, and 
all complications.  Putting a feature in C means making decisions like 
figuring out what type the expression "b..c" has, whether the various 
bits and pieces have to be constants or if they can be variables, how 
the operator precedences work, how to treat floating point numbers or 
mixes of different types, and countless other factors.  If a language 
already has the concepts, rules and grammar for ranges or lists, adding 
an "in" operator is natural - if not, then it's a huge amount of extra 
junk pulled into the language and syntax for a very minor gain.

I don't disagree that it could be useful, and I'm sure I'd use it if it 
existed in C, I just disagree that it makes sense in C.


> 
> 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 

You and I are British - the term is "half-arsed" :-)

> 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.
> 

If it were considered useful enough, it could be standardised in the C 
library.  If it is not useful enough to standardise in the library, it 
is certainly not useful enough to put in the language itself.

In practice, while I would put something like this in a new language, I 
don't think it is important enough to try to add to C.  When you need to 
do a lot of checks, you'd put them within a function (or macro if you 
prefer), such as "isspace()".