remove flipped variants of binary operator functions

[davidchambers]

#438 (comment)

[Avaq]

It looks good to me. I like this. Based on the comment you linked it seems you will fix the signatures in a later commit, but I'll mention it in case you wanted to do it in this commit and forgot.

[gabejohnson]

I'm slightly concerned that we're going to end up in the state we were in prior to #388. Perhaps if there's an entry in the wiki it won't be an problem.

[davidchambers]

Based on the comment you linked it seems you will fix the signatures in a later commit, but I'll mention it in case you wanted to do it in this commit and forgot.

Thanks, Aldwin. It's best not to assume everything I do is intentional. :)

In this case, I think we should stick with the _ -> (_ -> _) types until we update sanctuary-def in an upcoming pull request (at which point all functions will adopt this stricter behaviour). S.lt (0, 1) is currently a type error, and it will be a type error once simple currying lands. I'd like to avoid a window in which it is valid (evaluating to false).

[davidchambers]

I'm slightly concerned that we're going to end up in the state we were in prior to on #388.

Could you elaborate, Gabe? Your memory of the discussion preceding that pull request is likely better than mine. What are you concerned that users will incorrectly assume if we merge this pull request?

[gabejohnson]

I'm referring to the issues/comments linked to in #388 (review). In the past, there has been a lot of confusion around argument order for binary operators.

Although their behavior is documented, I suspect the first time a new user reaches for S.lt they will assume the wrong argument order. Perhaps calling out the non-commutative "operators" individually or putting them in their own subsection would help.

[davidchambers]

I suspect the first time a new user reaches for S.lt they will assume the wrong argument order.

Even though S.lt (x, y) will not be supported, Gabe? Feedback from Ramda and Sanctuary users gives me the impression is that the majority assume S.lt (0) to define the less than zero function.