Common combinators in JavaScript

combinators.js

const I  = x => x
const K  = x => y => x
const A  = f => x => f (x)
const T  = x => f => f (x)
const W  = f => x => f (x) (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 S_ = f => g => x => f (g (x)) (x)
const S2 = f => g => h => x => f (g (x)) (h (x))
const P  = f => g => x => y => f (g (x)) (g (y))
const Y  = f => (g => g (g)) (g => f (x => g (g) (x)))

combinators.md

Name	#	Haskell	Ramda	Sanctuary	Signature
identity	I	id	identity	I	a → a
constant	K	const	always	K	a → b → a
apply	A	($)	call	I¹	(a → b) → a → b
thrush	T	(&)	applyTo	T	a → (a → b) → b
duplication	W	join²	unnest²	join²	(a → a → b) → a → b
flip	C	flip	flip	flip	(a → b → c) → b → a → c
compose	B	(.), fmap²	map²	compose, map²	(b → c) → (a → b) → a → c
substitution	S	(<*>)²	ap²	ap²	(a → b → c) → (a → b) → a → c
chain	S_³	(=<<)²	chain²	chain²	(a → b → c) → (b → a) → b → c
converge	S2³	apply2way, liftA2², liftM2²		lift2²	(b → c → d) → (a → b) → (a → c) → a → d
psi	P	on	on	on	(b → b → c) → (a → b) → a → a → c
fix-point4	Y	fix			(a → a) → a

---

¹) The A-combinator can be implemented as an alias of the I-combinator. Its implementation in Haskell exists because the infix nature gives it some utility. Its implementation in Ramda exists because it is overloaded with additional functionality.

²) Algebras like ap have different implementations for different types. They work like Function combinators only for Function inputs.

³) I could not find a consistent name for these combinators, but they are common enough in the JavaScript ecosystem to justify their inclusion. I named them myself in order to refer to their implementation.

⁴) In JavaScript and other non-lazy languages, it is impossible to implement the Y-combinator. Instead a variant known as the applicative or strict fix-point combinator is implemented. This variant is sometimes rererred to as the Z-combinator. The implementation found in combinators.js is the strictly evaluated "Z" combinator, which needs the extra wrapper around g (g) on the right hand side.

references.md

Note that when I use the word "combinator" in this context, it implies "function combinator in the untyped lambda calculus".

• To Mock a Mocking Bird (book of combinatory puzzles and examples)
• Combinator Birds (summary of all combinators named by the book)
• CombinatorsJS (implementation of all the same combinators in JavaScripts)
• Fantasy Combinators (implementation of common combinators in JavaScript)
• Collected Lambdas (collection of noteworthy combinators)
• Programming With Nothing (talk)
• Church Encoding (wikipedia)
• Fixed-point combinator (wikipedia)
• Lambda calculus (wikipedia)
• SKI combinator calculus (wikipedia)
• BCKW combinator calculus (wikipedia)

Hey all,

I love this list and come back to it regularly.

I recently wrote a combinator and I'm trying to find out the name of it. I'll do my best to describe it here and perhaps someone who's knowledgeable in these things will know what it's called.

The function signature I've identified is: (a -> b -> c) -> (a -> c -> d) -> (a -> b -> d) which is a function that takes 2 binary functions. When a value is applied to the resulting function, that value is applied to both of the binary functions. When the next value is applied it is then applied to the second function in the composition, the result of which is applied to the first function in the composition.

It's a little bit like substitution but for 2 binary functions instead of 1 unary and 1 binary.

My implementation of this (using Crocks) looks like: const fooComb = converge(binary(compose));

Thanks again for maintaining this excellent list and I hope my explanation above is expressed clearly enough.

As far as I'm aware, @JamieDixon, that combinator does not have a name.

When a value is applied to the resulting function, that value is applied to both of the binary functions.

Functions are applied to arguments, not the other way around. f (x) is f applied to x. I know what you meant, of course. :)

Thanks @davidchambers

You are of course completely right, that functions are applied to arguments. I'm not sure why I wrote it that way around!

I'm excited to find out that I've produced a combinator without a name. Perhaps I shall name it 🙂

As far as your (a -> b -> c) -> (a -> c -> d) -> (a -> b -> d), could you provide an instance? It sounds a little like some things I've seen before and might be able to be abstracted. For instance, it seems like a flipped compose with an extra argument.

Hi,

I'm also curious to see an instance of that.

@danwdart @drupol Let me know if I've misunderstood what you're asking for, but here's how I make use of this function, including some example functions for my app:

const filterBodyProps = id => body => ...
const parseObject = id => obj => ...

// The combinator that is thus-far unnamed
// fooComb is now: (a -> b -> c) -> (a -> c -> d) -> (a -> b -> d)
const fooComb = converge(binary(compose));

const filterAndParseFields = fooComb(parseObject, filterBodyProps);

const result = filterAndParseFields("abc-123")({ name: "bob", price: "500"})

I've been wondering whether the first two functions should be swapped around to bring this more inline with the standard thinking around composition.

Reminds me of the Reader monad with composition.

@danwdart Yes! That's a great way to express it. In this case the id is the shared context and the rest is standard function composition.

For some reason it's easier for me to use the JS notation:

const FooComb  = f => g => x => y => g(x)(f(x)(y))

Is it good @JamieDixon ?

@drupol Looks good to me!

@JamieDixon: I came here wondering if the combinator I was about to write had a well-known name.

I guess not. But now I think FooComb may be stuck in my head!

@CrossEye Should I leave this earth having achieved nothing more than contributing the name fooComb to the collective parlance of combinatorial logic, I shall consider my time here well spent.

converge is not well-known in Haskell as apply2way. It is very well-known as liftA2 or liftM2.

Right, thanks for the heads-up @JohanWiltink. Noted.

S_ is also known in JS as "flatMap"
I'm making a paper / repo combination detailing some of the things you can do with these, and also including the appropriate Smullyan bird (if they exist) in them.

@JohanWiltink: Yes I always suggest people use Ramda's lift in preference to converge whenever they can. converge has some additional capabilities for JS's variadic functions, but unless they're used, lift is nicer.

@CrossEye I believe I still can't quite list R.lift as an implementation of (b → c → d) → (a → b) → (a → c) → a → d, because R.lift takes its first function argument in strictly uncurried form. As in, I think R.lift could be an implementation of ((b, c) → d) → (a → b) → (a → c) → a → d instead.

@Avaq: sorry, I wasn't suggesting that, only responding to something @JohanWiltink said.

And yes, it's not an implementation of that pattern, although the first argument can in fact be a curried function. The next functions, though, cannot be supplied separately. So you can do

lift ((a) => (b) => a + b) (x => x.a, x => x.b) ({a: 2, b: 3})  //=> 5

But not

lift ((a) => (b) => a + b) (x => x.a) (x => x.b) ({a: 2, b: 3}) //=> <nonsense>

So it's more like

(b → c → d) → ((a → b), (a → c)) → a → d

(although as usual with Ramda functions, the first argument can be uncurried or curried.)

I wasn't suggesting that [R.lift is a valid implementation of the converge combinator], only responding to something

I know, but when I saw your comment I flew in to add R.lift to the table, but then started to question whether I can. I commented just to verify. Sorry, it was a little unclear. :)

although as usual with Ramda functions, the first argument can be uncurried or curried

Oh, interesting. I didn't know Ramda functions are also overloaded in that respect. Also, I thought R.lift determines the arity for the lifted function based on the arity of the original, but I guess it uses the length of arguments supplied to the lifted result instead.

@Avaq:

I commented just to verify.

You're correct. lift is related, but not an exact match, as is Ramda's converge.

Also, I thought R.lift determines the arity for the lifted function based on the arity of the original, but I guess it uses the length of arguments supplied to the lifted result instead.

Your initial thought was correct. However if those two numbers don't match, it probably won't work.

And of course, this use of lift is still a fairly obscure one. I would expect it more for cases like

lift ((a, b) => a + b) (Maybe (25), Maybe (17)) //=> Maybe (42)

a → b → b is also useful:

const right = a => b => b;
const log = a => right(console.log(a))(a);

This behaves like identity function: a => a which does not affect to the original code but console.log(a) in the process.

It's possible to rewrite with a → b → a

const left = a => b => a;
const log = a => left(a)(console.log(a));

but, It's not intuitive in terms of the evaluation order.

@stken2050 Fortunately its trivial

const CK = C(K)

I don't see why console.log is a good case though. Maybe you meant 'tap':

const tap = (f) => (x) => {
  f(x);
  return x;
};

tap(console.log)(2)

// Or more usefully: 
doThing().then(tap(console.log))

It is impure though

@jethrolarson
Thanks.
Sure, log is IO and impure, and actually, I use the right for any IO operations.

Hello! Ramda v0.28.0 has shipped with some new functions, including on: https://ramdajs.com/docs/#on — Do you think we could update the table above?

It looks like that new on is actually the Psi combinator.

Thanks for the heads-up. Ramda on added to the table! 🎉

@JAForbes:

I have this as a pinned tab and I just stare at it sometimes like the obelisk in 2001.

Six years later, and I'm still doing that!

@Avaq: Thank you for a wonderful resource!

Thank you @CrossEye ❤️
I also still commonly refer to this resource, myself. :)

Same as gazing avianly at the Smullyan book, which I got in ebook after buying it physically.