more combinators

@Avaq raised the issue of combinators on Gitter. Sanctuary currently exports I and K, but fantasy-combinators defines several more, neatly summarized in a gist:

const I = x => x;
const K = x => _ => x;
const A = f => x => f(x);
const T = x => f => f(x);
const C = f => y => x => f(x)(y);
const B = f => g => x => f(g(x));
const S = f => g => x => f(x)(g(x));
const P = f => g => x => y => f(g(x))(g(y));
const Y = f => (g => g(g))(g => f(x => g(g)(x)));

A is a strict version of R.call (since it expects a unary function).

C is a strict version of S.flip (since it expects a curried function).

B is S.compose.

I’d like Sanctuary to provide more of these combinators. I’d welcome a pull request for one or more of these functions. 😃

[jethrolarson]

Aw yes, the C, A, T, S, P, Y, B, I, K system

[Avaq]

Hi @davidchambers!

In all honesty I have to say I’m still a bit skeptical about the decision to add more combinators to Sanctuary. There are several points I’d like to make.

---

Firstly, as I’ve come to understand, combinators have their roots in Lambda calculus. The Y combinator specifically -I believe- is a way to gain recursion in an environment where there is no variable assignment other than Lambda binding. That’s the main problem is solves. The point I’m trying to make here is that we can do other types of variable assignment in JavaScript, so it’s really quite easy to create recursive functions without help from the Y combinator:

//With Y:
const factorial = Y(f => n => n < 1 ? 1 : n * f(n - 1));
//Easier to read and just as easy to write without Y:
const factorial = n => n < 1 ? 1 : n * factorial(n - 1);

So the only application it has in JavaScript (as far as I can see), is to enable writing point-free recursive functions:

//Without Y:
const helper = n => factorial(n); //I need this pointful helper :(
const factorial = ifElse(isZero, K(1), S(mult)(B(helper)(dec)));
//With Y:
const factorial = Y(B(ifElse(isZero, K(1)))(B(S(mult))(C(B)(dec))));

Now, besides the fact that it took me close to two hours to create the point-free version (marvel at its beauty), it’s also quite cryptic as far as readable code goes. This leads me to conclude that usage of the Y-combinator is very practical in lambda-only environments, but maybe not so much in environments that support self-referential functions.

---

Secondly, I think the idea in combinatory-logic is for the combinators to be defined in terms of only unary lambda’s or other combinators. Defining them using sanctuary-def defeats that philosophy/practice, which is okay because we’re basically just porting over the utility that they provide. But then wouldn’t it be better to just name the utility functions after the problem they intend to solve? And wouldn’t you then end up with S.flip and S.compose etc?

---

Thirdly, it’s still my opinion that Sanctuary is better off remaining lean, and including only the necessary functions to allow for safe JavaScript. It already has a bunch of utility functions which could be classified as combinators, which it includes out of need.

---

Conclusion: I said I would gladly submit a pull-request for the Y combinator, and as much as I would like to find out if sanctuary-def can deal with its absurd type signature, I can’t help but wonder how much value I would really be adding to the code-base.

I’d love to hear your thoughts!