Re: Interval Comparisons

On 04/06/2024 16:16, bart wrote:

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.
 

It might be that we would agree on that if we worked hard enough to find a common definition for "that level of language".  But I think that would be a lot of time and effort for little purpose.  I do agree that with enough limitation in the scope of the feature, it is less unreasonable for a low-level language.  But I think I would want to limit the scope until there is little point in the "in" operator - or I would want to go the other direction and define something like Pascal's sets with many more operators and uses.

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.

Yes.

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

I see your point, but I rate the design and use of a language as /much/ more important than the ease of implementation.  I realise the balance is a bit different when the user is the implementer.

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.

We can educate them!

 (Actually I'm not quite considered British enough to be allowed in the upcoming election.)
 

I can't vote either, but that's because I don't live in the UK.  And given the state of UK politics these days, I'm happy to be out of it. For quite a while, the Scottish Parliament were looking like the adults in the room, but they've managed to mess things up for themselves too.