Re: Interval Comparisons

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.