ord: add comparison functions

[davidchambers]

These functions should be uncontentious.

[kedashoe]

What about ramda/ramda#1497?

[davidchambers]

What about ramda/ramda#1497?

It seems to me there's no perfect solution to this problem. I've wavered, but my current position is that the placeholder is the best of several compromises.

[kedashoe]

Personally I agree with what you wrote at the top of the thread

One can easily write x < y if both values are known, so these functions are primarily useful in conjunction with partial application. Let's optimize for partial application (as we do elsewhere in the library).

I've argued along those same lines when it has come up before on ramda. I honestly never use these functions except when curried.

Would be curious to hear what others think..

[davidchambers]

Pinging @Avaq, @JAForbes, and @scott-christopher for input. I'm in two minds, but not including these functions in the library just because there's no unequivocally correct argument order seems unreasonable. I'm happy to make S.gt(0)(42) equivalent to 42 > 0 if there's sufficient support for switching.

[scott-christopher]

I think I have always been on the side of wanting these to be thought of as unary functions that return predicates in Ramda, so I would be in favour of S.gt(0)(42) === 42 > 0 here.

[JAForbes]

I'm very much in favour of S.gt(0)(42) being equivalent to 42 > 0 🎆

[CrossEye]

Are these then unary functions? That's always been one possibility for Ramda.

// gt :: Ord a => a -> (a -> Bool)

If they're binary like Ramda's

// gt :: Ord a => a -> a -> Bool

then I think there is equally surprising behavior when these are fully applied. Many users are sure to be confused by gt(0, 42); //=> true.

[SeanCannon]

Thanks for even bringing this up - I always felt Ramda's were backwards. I want to be able to do const isGreaterThanThree = R.gt(3); vs R.gt(R.__, 3) which is just ridiculous imo.

[JAForbes]

@CrossEye has made a strong case for ramda's behaviour on gitter.

I still find myself sighing aloud whenever I reach for these functions and need to use the placeholder, or an arrow function But I see value in thinking of these functions as language operators. Recently I've been programming build scripts in livescript with infix syntax, and it makes me thankful for ramda's design in those contexts. I imagine there's plenty of scenarios where retaining an operator inspired api would pay off, and I think I'm just not as good of a programmer as @CrossEye so I've simply not encountered them yet.

If these functions aren't treated as operators, then other functions like concat should reverse the arg order too. And I think a change like that would be frustrating for users. I'd prefer consistency overall, than the minor annoyance of having to use the placeholder in those rare cases that gt etc comes up.

I think I'd be in favour of gt acting like ramda, and bringing in some convenience predicate functions like isGt. I've seen that suggestion come up in the past, and it has grown on me.

Context matters, in the context of a library like sanctuary, I think consistency is pivotal. So I'm at the very least changing my vote to "wavering" like @davidchambers, mostly due to @CrossEye's reasoning.

[gabejohnson]

@JAForbes It's funny you mention concat, because I have found the arg order there to be inconsistent with the rest of the library. It's even tripped me up a few times.

let append123 = S.concat(S.__, [1,2,3]);
// vs
append123 = S.concat([1,2,3]);

This just may be my bias and not necessarily representative of a community.

But to the point, consistency would require changing sub and div as well I think (along w/ whichever functions Sanctuary has in common w/ the bolded items in ramda/ramda#1497 (comment)). But I question why you would be using binary functions instead of operators in the first place. It makes sense in a transpiled language that allows Haskell-style infix syntax, but no way can we assume that's going to be the common use-case.

I agree w/ @tycho01 in ramda/ramda#1497 (comment)

[davidchambers]

I've updated this pull request. It now introduces eight functions:

• lt
• lte
• gt
• gte
• lt_
• lte_
• gt_
• gte_

Although all eight functions are binary, the unsuffixed ones can be considered unary. lt(10), for example, is the less than 10 function. I chose this naming scheme because it matches the naming of functions such as reduce (which expects a curried binary function) and reduce_ (which expects an uncurried binary function).

If we decide to merge this pull request we should first update existing binary functions accordingly. sub, for example, should be renamed sub_ and a new sub function should be defined such that sub(10) is the subtract 10 function.

What do you think of lt/lt_, sub/sub_, and friends? 👍 / 👎 ?

[KiaraGrouwstra]

It sorta invokes @TheLudd's remark here, but sounds like the lesser evil.

[davidchambers]

The difference being, @tycho01, that Sanctuary currently does use the _ suffix quite consistently.

[KiaraGrouwstra]

Fair enough. :)

[kedashoe]

Maybe prefix the underscore (ie _lte) to indicate flipped operators so the current meaning of the underscore suffix can remain distinct? Personally I would rather not include them.. but I guess it could be useful for the type checking?

[davidchambers]

Maybe prefix the underscore (ie _lte) to indicate flipped operators so the current meaning of the underscore suffix can remain distinct?

I see the two uses as related:

• the _ in lt_ indicates that the function expects all its arguments at once; while
• the _ in reduce_ indicates that the function argument expects all its arguments at once.

Even if one considers the above a stretch, the _ suffix can at least indicate that the function is looked upon less fondly than its unsuffixed relative. I don't think we should introduce prefixes. We could end up with foo, foo_, _foo, foo$, and $foo if we're not careful. 😜

[kedashoe]

We could end up with foo, foo_, _foo, foo$, and $foo if we're not careful. 😜

ha! Alright, if you want to include them, suffix seems okay to me 👍

[CrossEye]

Hey, why not go for foo_$$___$_$ while we're at it? We could have a whole bitmask of flags for every function. 😄

[gabejohnson]

What about lte/precedes and gte/succeeds? Not sure which would be unary.

[davidchambers]

I'll close this pull request, as fantasyland/fantasy-land#235 will soon deliver something better. :)

[KiaraGrouwstra]

@CrossEye:

Hey, why not go for foo_$$___$_$ while we're at it? We could have a whole bitmask of flags for every function. 😄

Sanctuary may be safe (pun not intended), but I fear a certain other library may not remain so fortunate!

[gabejohnson]

I have an updated proposal in #391 (comment) inspired by Haskell's infix operator sections.