Add left section, right section and infix functions

See https://github.com/sanctuary-js/sanctuary/pull/391#issuecomment-300962716.

To resolve the issues in #1497 regarding associative, non-commutative binary “operators” I propose adding three new functions inspired by how Haskell deals with infix operators:

// leftSection :: (a, (a -> b -> c)) -> b -> c
// abbreviated _l
const _3subtract = R._l(3, R.subtract);
_3subtract(5); //=> -2

// rightSection :: ((a -> b -> c), b) -> a -> c
// abbreviated _r
const subtract3 = R._r(R.subtract,  3);
subtract3(5); //=> 2

// infix :: (a, (a -> b -> c), b) -> c
// not sure if it needs abbreviating. possibly _in
R.infix(3, R.subtract, 5); //=> -2

Before submitting a PR I’d like to get the semantics locked down. Specifically, should these functions be curried?

My initial thinking is no. These functions are mainly to aid in intent/readability. The examples for the section functions could be rewritten:

const _3subtract = R.subtract(3);
_3subtract(5); //=> -2

const minus3 = R.subtract(R.__, 3); // or R.flip(R.subtract)(3)
minus3(5); //=> 2

This shows that there is no use for curried R._l, and curried R._r is equivalent to R.flip. But the intent is lost.

Without the fully qualified noise:

// 3 subtract 5
_l(3, subtract)(5); //=> -2

// subtract 3 from 5
_r(subtract, 3)(5) //=> 2

// 3 subtract x is less than 5
pipe(_l(3, subtract), _r(lt, 5))( 12 / 3 ); //=> true

The weakest proposal appears to be for infix. After all

infix(1, lt, 2) //=> true

// can just as easily be written
1 < 2 //=> true

But it makes more sense once #1900 is released.

infix([1, 2], lt, [2, 1]) //=> true

@CrossEye I got bored yesterday 😄

[gabejohnson]

@buzzdecafe would you be in favor of removing _isPlaceholder from the curry functions and changing the semantics of __ to the proposed __(__, fn, arg)?

The next best thing IMO is to go with f_, _f, and _f_ or some such while deprecating __.

[CrossEye]

I don’t know how it was I never participated in this. This is a great proposal. But I’m torn.

On the one hand, I really like this idea. I’m more in favor of the f_/_f version than the Clojure-inspired __(a, f, b) one. But, while I agree these are better than _l/_r, is there any reason not to simply go with left/right? Perhaps, I suppose, if we think we ever want to support Either directly. There might be some reason for them, then.

On the other hand, this does not solve the problem that lte, etc. will always be surprising in one form or another. It gives us an alternative way to write such things, but it doesn’t remove the surprise. @davidchambers pointed out that the only real solution would be to fully curry our functions. I’m coming more and more to want to do that post-1.0, even if that does change the character of Ramda a fair bit. However, if we do that, how much need would remain for such section functions?

So I’m torn.