Re: Interval Comparisons

On 10/06/2024 17:33, bart wrote:

On 09/06/2024 12:26, David Brown wrote:

On 07/06/2024 14:20, bart wrote:

On 07/06/2024 12:17, David Brown wrote:

If that is your intent, then fair enough.  But I think that is an unusual intent.

 Really,  checking that A and B both have the same value X is that unusual?

No.  But checking that A and B have the same value, then checking that one of them as the same value as a constant X, is - I would say - definitely an unusual way to think about things.  It is more natural to check if A is equal to X, and if B is equal to X.
You seem to disagree with that.  Fair enough, it is a subjective opinion.

>
I don't think it is fair to claim particular ways of writing these things are always clearer, or better, or uglier, or unclear - it will depend on the rest of the language, and how the code is used.  But in general I think it helps to write code that follows the logic of what the writer really means, rather than alternative constructions that give the same result.

 Using function-like syntax is OK when you have the same operator between multiple terms. 'rising' could have '<' or '<='.

Yes.  I think that is almost certainly what you would want, except in the case of checking if a value is in a half-open interval.  I would be happy with an "in" operator and ranges of some sort for that case.

 All-equal would have the same operator too, but it looks clunkier, and a bit over-the-top:
     a = b                2 terms
    all_equal(a, b, c)   3 terms using your feature
    a = b = c            3 terms using chained ops
     rising(a, b, c)      Using your other feature
    a <= b <= c          Using the same chained-op feature
 

I guess a lot of this ends up as a matter of taste.

Your solution requires a heavyweight language feature. It also looks like it will generate a lot of intermediate code that will need a heavyweight optimiser to tear down again.
 

I place approximately zero weight on requirements for code generators to be optimising.  It is irrelevant to the user - it only matters to the implementer of the tools.  It does have to be /possible/ to implement the feature, but it does not matter if the compiler has to optimise well to make it efficient.