Re: Interval Comparisons

On 04/06/2024 14:24, David Brown wrote:

On 04/06/2024 13:23, bart wrote:

On 04/06/2024 12:02, David Brown wrote:

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 was responding to your comment:
"and that kind of feature would be well outside the scope of the language."
I think it can suit that level of language if you avoid being too ambitious.
I agree it is not practical to apply to C at this point, not without making it ugly or unwieldy enough that people might as well use existing solutions.
(Such a feature also aids simpler non-optimising compilers. Take these examples that all do the same thing:
     if a <= f() and f() <= c then fi
     if a <= f() <= c then fi
     if f() in a..c then fi
If the two f() calls in the first example were considered common subexpressions, I don't have the means in my compiler to detect that that and evaluate them just once.
In the other two examples, the language lets you express that directly.
Even for a simpler 'b in a..c' example, it is easier to generate more efficient code, and do that more efficiently too than building something up only to tear it down again.)

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" :-)

I'm catering for a wider readership.
(Actually I'm not quite considered British enough to be allowed in the upcoming election.)