Intro to Functional Combinators in Javascript

#javascript #functional #computerscience #beginners

Functional programming is at its core about using functions as the primary means of building programs. This means that a constructed functional program is a function. To those accustomed to OOP it might seem absurd to only use functions but with the power and simplicity of function composition and a few additional concepts you can create testable applications of any size. As a quick intro I want to focus on a couple concepts that can help build complex programs from smaller ones.

Compose

You may remember this one from High School math class as "compose" or just "°". Given two functions f and g (g ∘ f )(x) = g(f(x)). We can implement this in JS as

const compose = (g, f) => (x) => g(f(x))

This is a higher-order function, that is, a function that either takes a function as an argument or returns one. Compose does both, taking two functions and then returning one that applies its argument to the second function and then applies the result to the first one. Let's create a couple example functions to illustrate:

const inc = n => n + 1;
const half = n => n / 2;

const operate = compose(half, inc);

console.log(operate(3)) //=> 2

There's an important constraint to consider; the compose function only works on functions that take one argument (unary functions). Doubly troublesome is that compose itself takes two arguments so it can't be used in a fractal manner. That wont do. Fortunatly there's a cool trick to make any function unary: currying.

Currying

Currying is the act of converting a function that takes multiple arguments into a function that takes the first argument and returns a function that takes the next recursively until all arguments have been passed before returning the result. As an example let's refactor the inc function from above to be based on an add function:

const add = (n, m) => n + m;

The above add function is a normal two-argument(binary) function but we can jam an arrow between n and m to curry it:

const add = n => m => n + m;
// now that its curried we can partially apply it to create 
// our inc function from before
const inc = add(1);

Compose revisited

Now that we know how to curry let's curry the compose function itself. This is also known as the B-combinator so let's call it that here:

const B = g => f => x => g(f(x));

// usage is similar to before
const operate = B(half)(inc)

You may find it hard to think about what a partially-applied compose function is. I like to think of it as a program that has an adapter on it perfect to fit another program. B(half) is a function that will take a program and return one that divides the result by two.

One of the great places to use this is anywhere you see nested function calls:

const process = (arr) =>
  arr.map(a => 
    getUser(getFirstName(a))
  );

// can be rewritten as
const process = (arr) =>
  arr.map(B(getUser)(getFirstName));

This is just the tip of the iceberg and I invite you to try writing these yourself and playing around with them.

Top comments (8)

John Peters • Jan 3 '20 • Edited

Thanks Jethro, really nice article, something for me to study in coming weeks for sure.

I was an OOPer for over 15 years. The main take away was the SRP principal (Single Responsibility Principal). Once I learned to assess my brand new block of code and follow that rule, it lead me to the next step. If there were any mixed responsibilities, I immediately refactored them to a new method. This ultimately allowed me to see the end result which was lots of small re-usable (functions) methods. OOP leads us to functional programming styles when we take the SRP principal seriously.

Its not really that different than the DRY principal. Reason? Because if you never repeat your code, you are forced to the functional and composition styles.

Jethro Larson • Jan 3 '20

I agree. But I've also heard the assertion "functions in the small, objects in the large", so I wanted to emphasize that it is possible and potentially a good idea to use functions all the way up

John Peters • Jan 3 '20 • Edited

Yes no problem with that idea. As we build reusable parts, we have no choice but to use Composition as our style, which you referred to in this article. Nice...

If we use only composed functions it is no different than using composed classes. OOPers have been composing classes for 30 years now. The concepts are identical. So really. It's a matter of containment and how to implement.

AFAIK, Typescript compiles everything down to functions anyway.

Jethro Larson • Jan 3 '20

Depending on your compile target, yeah. However, those constructor functions create objects and v8 turns objects into hidden classes so everything is everything :)

blog.sessionstack.com/how-javascri...
See also wiki.c2.com/?ClosuresAndObjectsAre...