Re: Interval Comparisons

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