DEV Community: Justin Morgan

Loops, Array Methods, and Recursion

Justin Morgan — Thu, 18 Nov 2021 23:22:01 +0000

"Loops" are an extremely powerful abstraction in computing and for loops are often the entry point for most programmers into the topic. This level of abstraction is very primitive and can lead to writing quite inelegant, indirect, and often error prone code. There are several other versions of the loop as well as more specialized approaches to tackling the same category of problems.

We'll start with the explanation of what a loop, as an abstraction, offers programmers. Then we'll discuss how "looping" manifests in Javascript. Finally we'll discuss how we can tackle the same problems with functional-programming strategies: array-methods/functions and recursion.

What is "Looping"?

If we imagine our computer as a machine executing our code, a series of "operations", we immediately see the benefits of a machine reliably and reproducably performing mechanical work. For example, we can think of the summation of 1,000,000 figures from an accounting record. If we consider how we would describe this process doing it by hand, we may say something like:

- for summing a list of 1,000,000 things, 
    - we have a starting value of 0, 
    - take the items one at a time, 
    - each step add the taken item to our starting value, then use that as our next starting value
    - start with the first item in the list
    - stop when there are no more items in the list
    - finally, examine the updated starting value (the "sum")

From this description, we can distill the basic concepts of looping:

a notion of a "set" which we want to perform a repeated operation upon,
an initial state,
how we are going to traverse the set,
an operation defined that we want to perform repeatedly,
a starting condition,
an ending condition, and
a final operation

Not coincidentally, I described the pattern for what is generally considered the most primative type of loop: the for loop. So let's start with an examination of this loop as our launching point.

Types of Loops

For Loops

A for loop, at least conceptually, is the building block of most other loops. It satisfies all the qualities of looping described above. In Javascript, it has the form:

for(<starting_condition>; <ending_condition>; <how_to_progress_after_each_step>;) {
    <work_to_do_at_each_step>
}

While this annotation doesn't directly map to the above described qualities of looping, actual implementations make it more apparent that it does in fact correspond. Let us consider summing a list of 1 million numbers, stored in an array.

function forSum(array_of_numbers, sum = 0) {
  for(let i = 0; i < array_of_numbers.length; i++) {
      sum += array_of_numbers[i]
  }
  return sum
}

Here it is more apparent that each quality of a loop is addressed. Our set (array_of_numbers), operation to perform repeatedly (+=), initial state (sum = 0), starting condition (let i = 0 or "start with the starting index of the array"), ending condition (i < array_of_numbers.length or "until the index is one less than the length of the array"), and a final operation (return).

Another important quality of "looping" is the ability to stop midway through the process and to skip certain steps. These concepts are embodied in Javascript with the keywords break and continue.

With break we can abort the remaining steps, essentially overriding the ending condition. This is often referred to as short-circuiting. The purpose of this is to both improve efficiency--by not requiring the procedure to run a bunch of extra times--and to avoid the need for including "by-pass" code (code which essentially does nothing just to reach the completed state).

Continue allows for an immediate jump to the end of the block of code contained within the loop. This too allows for avoiding certain types of "useless" code.

Take this contrived example of summing the natural numbers from 1 to some unknown number, discarding all numbers that are multiples of 2 or 3, stopping once the sum reaches a certain target. We want to return the sum that exceeds the supplied target as well as the list of numbers that make up that sum. We don't know how many numbers that will take, so we will make our ending condition "while our current number is less than Infinity".
function takeNonMultiplesOfTwoOrThreeUntilSumIs(target) {
  let sum = 0
  let nums = []
  for(let i = 1; i < Infinity; i++) {
      if (i % 2 == 0 || i % 3 == 0) continue;
      if (sum >= target) break;
      sum += i
      nums.push(i)
  }
  return [sum, nums]
}
This can be accomplished in other manners, but the inclusion of these keywords can often avoid extra code.

Using the for loops as an initial point of reference, we can consider variations that fix one or more of the above "knobs" and give us more particularlized behaviour. This is done for convenience and it should be noted that each of the other loops can be implemented with a for loop.

While Loops

A while loop appears a lot more streamlined, but its obvious applications are fairly specific. A while loop reduces the number of parameters from three (starting condition, ending condition, traversal instruction) down to 1 (ending condition). It disguises the other two parameters: the ending condition is established by monitoring a value outside the loop definition, and the traversal logic is (often) contained within the loop's block:

function whileSum(arrayOfNumbers, sum = 0) {
  while (arrayOfNumbers.length) {
    let num = arrayOfNumbers.pop();
    sum += num;
  }
  return sum;
}

While certain circumstances benefit from this format, it does require special care not to create an "infinite loop". This is because there are a limited set of Javascript values which are falsey. Because the end condition cannot be set in terms of a parameter of the loop, it is easy to make a mistake here.

As with the for loop, break can be used to short-circuit the entire loop and continue can be used to short-circuit the current iteration.

Do-While Loops

Very similar to a while loop, the do-while loop runs its execution block (the do block) before checking the while/end condition. The syntax includes a do block followed by a while statement:

function doWhileSum(arrayOfNumbers, sum = 0) {
  do {
    console.log(`Number of items left to sum: ${arrayOfNumbers.length}`);
    if (!arrayOfNumbers.length) {
      console.log("No items to sum");
      break;
    } else {
      let num = arrayOfNumbers.pop();
      sum += num;
    }
  } while (arrayOfNumbers.length);
  return sum
}

For-Of Loops

A relatively recent addition to Javascript is the for...of loop, which iterates over all of the values in an iterable object (objects or arrays alike) (MDN docs here).

A for...of solution could look like:

function forOfSum(arrayOfNumbers, sum = 0) {
  for(let num of arrayOfNumbers) {
    sum += num
  }
  return sum
}

For-In Loops

There is also a for...in loop which iterates over keys and includes some you may not expect.

The for...in statement iterates over all enumerable properties of an object that are keyed by strings (ignoring ones keyed by Symbols), including inherited enumerable properties.

...

Given that for...in is built for iterating object properties, not recommended for use with arrays, and options like Array.prototype.forEach() and for...of exist, what might be the use of for...in at all?

It may be most practically used for debugging purposes, being an easy way to check the properties of an object (by outputting to the console or otherwise). Although arrays are often more practical for storing data, in situations where a key-value pair is preferred for working with data (with properties acting as the "key"), there may be instances where you want to check if any of those keys hold a particular value.

(Source - MDN docs)

A contrived example would be to filter out values in an array that are at indices that are divisible by 2 or 3:

function forInSum(arrayOfNumbers, sum = 0) {
  for(let index in arrayOfNumbers) {
    if (index % 2 == 0 || index % 3 == 0) continue;
    sum += arrayOfNumbers[index]
  }
  return sum
}

Note that in a for-in loop, we are working with keys of an object (or indices of an array in this simple example). In order to work with the values, we need to take the additional step of reading the value with the given object-key of the current iteration of the loop.

Loops: Final Thoughts

Loops work on sets of data, be it an array, an object, strings, or one of the more exotic new objects. Definitionally, a set can be of any size including a single item or an empty set. An example of a loop operating on an empty set is as follows:

while(true) {
  console.log(Date.now())
}

The loop is not tied to the data that it works upon, it merely describes an algorithm for repeatedly computing. While operating on sets in this way feels very flexible, it can be very error prone to consistently reimplement common patterns of object access. Therefore, it is very useful to consider using well established access patterns that exist, as we will consider next.

From Loops to Array Methods/Functions

When introducing the concept of a loop, we described that a loop works on a "set". In Javascript, this translates to mean an iterable object which includes most commonly objects, arrays, and strings.

If we focus our thinking to arrays for a moment, we can consider another class of solutions as an alternative to loops.

Before concluding that limiting our discussion to arrays is a significant limitation, consider that objects, strings, and other objects each have methods which will convert the object to an array (ex. Object.values, String.prototype.split, etc).

When traversing an array, we can often use array methods to complete those tasks more explicitly than a loop will permit. Loops are relatively low level operations that require us to implement much of the logic ourselves. Many array methods define a clear intent for common operations and they can be chained together using the "dot" syntax. For example:

someArray
  .filter(...omittedFilterFunction)
  .map(...omittedMapFunction)
  .forEach(...omittedForEachFunction)

If you are performing some "side-effect" with each value in an array, there is forEach. If you are transforming each value, there is map. If you are conditionally rejecting values, there is filter. If you are "accumulating" values, there is reduce.

Accumulation can take many forms, but basically it means that you are starting with some value (commonly call the accumulator) and then using each element in the array to update the accumulator. You can find the documentation for these methods on the MDN site:

forEach,

map,

filter, and

reduce.

There are several other built in array methods to consider, but these are the most common ones to consider. Additionally, their relationship to one another should provide insight into the "declarative" advantage over loops.

Reduce

Array.prototype.reduce is the for loop of array methods. It is the least declarative type of array iteration method and can be used to implement every other built-in array iteration method. In short, reduce iterates over an entire array, allowing for custom logic for copying and/or transforming of the original array's items into a new array (also known as the "accumulator").

The reduce method takes a callback which is called once for each value in the array and an initial value for your accumulator. This callback's signature is (accumulator, currentValue, currentIndex, originalArray) => accumulator (provide only as many parameters as you require, generally (accumulator, currentValue).

If you're unfamiliar with this pattern of "variable" function arguments, I have written an article on function arity in Javascript.

The value from accumulator is then passed as the first argument on the next iteration. It is easy to accidentally not return a value from your callback, especially when using an array function.

For example, if we want to implement a FizzBuzz function for an arbitrary array of numbers:

const arrayToBeFizzBuzzed = 
  Array(100)
    .fill(Infinity) // Array must have assigned value to map
    .map((_, i) => i + 1) 

const isFactorOf = (factor) => (testNumber) => !(num % factor)

const FizzBuzzReduce = (numbers, startingAccumulator = []) =>
  numbers.reduce((accumulator, num) => {
    if (isFactorOf(15)(num)) return [...accumulator, "FizzBuzz"];
    if (isFactorOf(3)(num)) return [...accumulator, "Fizz"];
    if (isFactorOf(5)(num)) return [...accumulator, "Buzz"];
    return [...accumulator, num];
  }, startingAccumulator);

Or if instead we wanted to filter out those values:

const FizzBuzzFilterReduce = (numbers, startingAccumulator = []) =>
  numbers.reduce((accumulator, num) => {
    isFactorOf(15)(num) || isFactorOf(3)(num) || isFactorOf(5)(num) 
    ? accumulator
    : [...accumulator, num];
  }, startingAccumulator);

The basic idea here is that we are traversing the array and conditionally transforming the items in it (in the first case) and conditionally appending it to the accumulator (in the second case). Whether the item is transformed or not, a new copy of the accumulator is returned from the callback function to be used for the next iteration (with the next item in the array).

Rewriting our summation above using reduce would look like this:

function reduceSum(arrayOfNumbers) {
  return arrayOfNumbers.reduce((acc, num) => acc += num, 0)
}

Map

Map particularizes reduce by handling the copying of the transformed value into the accumulator in a default manner. Whatever value is returned from the transformation function is appended to the accumulator. So the above example could be rewritten as:

const FizzBuzzMap = (numbers) => 
  numbers.map(num => {
    if (isFactorOf(15)(num)) return "FizzBuzz";
    if (isFactorOf(3)(num)) return "Fizz";
    if (isFactorOf(5)(num)) return "Buzz";
    return num;
  })

You can therefore think of map as the following particularization of reduce (written as a plain function, not a prototype method):

const map = (array, transformer) => {
  return array.reduce((accumulator, currentValue) => {
    return [...accumulator, transformer(currentValue)]
  }, [])
}

Filter

Filter particularizes reduce by handling the conditional copying of the item into the accumulator in a default manner. Unlike map, the value being iterated over is left unchanged in the resulting array. Rather, the truthiness of the value determines whether the value is copied to the accumulator or rejected (and the accumulator being passed on unchanged). So the above example could be rewritten as:

const FizzBuzzFilter = (numbers) => 
  numbers.filter(num => {
    return isFactorOf(15)(num) || isFactorOf(3)(num) || isFactorOf(5)(num) 
  })

You can therefore think of filter as the following particularization of reduce (written as a plain function, not a prototype method):

// A predicate function must have a unary function signature
// and should be interpretted as returning a truthy or falsy value
// ex. const isOdd = num => num % 2
const filter = (array, predicateFn) => {
  return array.reduce((accumulator, currentValue) => {
    return predicateFn(currentValue)
    ? [...accumulator, currentValue]
    : accumulator
  }, [])
}

forEach

Array.prototype.forEach is an array method which iterates over each element in an array but returns undefined. It is useful for performing side-effects on items in an array. It therefore cannot be chained onto by other array methods. It is most similar to map, though the return value of the callback function is not useful.

const FizzBuzzLogger = (numbers) => 
  numbers.forEach(num => {
    if (isFactorOf(15)(num)) return console.log("FizzBuzz");
    if (isFactorOf(3)(num)) return console.log("Fizz");
    if (isFactorOf(5)(num)) return console.log("Buzz");
    return console.log(num);
  })

And Beyond!

From this starting point, we can survey array methods that are further particularizations. The [MDN Docs] list several very useful ones (.every, .some, .reverse), some more infrequently used by my experience (.lastIndexOf).

If this approach interests you, you can dive even deeper by surveying the various array functions available in popular utility libraries suchs Lodash and (for even more extreme examples) Ramda. These libraries include composable functions (not array prototype methods) that are extremely useful once you get familiar with them.

One such function that I am sad is not a prototype method is zip. Zip takes two or more arrays and combines them into new items, one element from each array and halting at the point of the shortest array. For example:

const arr1 = ["a", "b", "c"]
const arr2 = [1, 2, 3, 4]
const arr3 = [10, 20, 30, 40, 50]
_.zip(arr1, arr2, arr3)
// [["a", 1, 10], ["b", 2, 20], ["c", 3, 30]]

The above uses the version of zip from Lodash (which allows more than two arrays to be zipped together--Ramda is limited to two arrays).

These sorts of specialized array methods can be implemented using reduce but it requires a non-trivial amount of work (not to mention edge cases that need to be considered). It is therefore wise to turn to a well tested utility library if you wish to code in this style.

Recursion

Another approach to replacing loops is to use recursion (the repeated call of the same function by itself). The approach is requires knowing that your function can call itself from within its own definition. This could happen infinitely if you don't provide a stopping condition (similar to the stopping condition of a loop).

As an example, we could code our FizzBuzz function as follows:

function recurFB(nums, acc = []) {
  let [num, ...rest] = nums

  if (!nums.length) return accumulator 
  if (isFactorOf(15)(num)) return recFB(rest, [...acc, "FizzBuzz"])
  if (isFactorOf(3)(num)) return recFB(rest, [...acc, "Fizz"])
  if (isFactorOf(5)(num)) return recFB(rest, [...acc, "Buzz"])
  return recFB(rest, [...acc, num])
}

Unfortunatly, recursion has some limitations in Javascript. Chiefly, the current implementation in all major browsers and Node versions do not do what is known as tail-call optimization.

When a function executes, it creates an execution context which establishes an alotment of memory for variables within the execution block of the function. Each call of a function creates such an execution scope, and so recursive function calls create a new execution context for each recursive call. As you may imagine, the more recursive calls, the more memory alotted. And at a certain point, this can lead to the runtime crashing.

The problem is that a function which calls itself in its body doesn't "finish" at that point and so its allocated system resources are not released. You may think to yourself "that's silly, the work is done". If you refer to the example implementation of a recursive FizzBuzz, you will see that there really isn't any work left except to recursively call itself. This is not always true but in this example I have defined the function in a way that is tail-call optimized. This means that all of the work of the function is completed but for a final call to execution of the function.

You can imagine that in theory, if the runtime could detect this, it could execute the recursive call in a separate context (not nested within the parent function) and release the resources allocated to the parent caller. This is known as tail-call optimization and many languages do this. Node even implemented it for a few versions but then removed it.

So is there a workaround? Yes, but arguably it makes the whole exercise look a lot more like a loop. One solution I've hear referred to as a recursive "trampoline". That is, the recursive call isn't truly a recursive call but rather a plain function call whereby the parent simply orchestrates the accumulation of each successive calls to the quasi-recursive function. Let's consider our above example.

First, we have to implement a trampoline utility function. This function is general enough that it can be used for all recursive functions that follow the trampline-pattern. The recursive function must then be modified slightly, returning an anonymous function which will, upon execution, call the next iteration with the appropriate arguments (stored in the anonymous function's closure scope).

const trampoline = fn => (...args) => {
  let result = fn(...args)
  while (typeof result === 'function') {
    result = result()
  }
  return result
}

function recurFB(nums, acc = []) {
  let [num, ...rest] = nums

  if (!nums.length) return accumulator 
  if (isFactorOf(15)(num)) return () => recFB(rest, [...acc, "FizzBuzz"])
  if (isFactorOf(3)(num)) return () => recFB(rest, [...acc, "Fizz"])
  if (isFactorOf(5)(num)) return () => recFB(rest, [...acc, "Buzz"])
  return () => recFB(rest, [...acc, num])
}

// Notice that each iteration returns a function expression 
// rather than immediately executing

Here we return a function from each pseudo-recursive call. In the trampoline function, we test whether the return value is a function and if so, execute it in a new context (freeing the resources from the prior call to be garbage collected). Finally we return the non-function value at the terminal case of our recursion.

But what if your "final" value is a function itself, just not the same function? 🧐

While recursion can be useful and elegant in many cases, it needs to be noted that this limitation exists in Javacript. Many times the context will not practically conflict with this limit but if your solution needs to be general then it is probably wise to prepare your function to avoid this limitation (either by using a loop or expressing your recursion as a trampoline-style function).

Conclusion

Loops and the array methods/functions described above both tackle the same category of problems. But is one interchangable for the other? Can we simply prefer one approach and disregard the other? In short, loops are the abstraction over even lower-level computing operations that we don't contend with in Javascript. And loops are the building blocks in which the array-functions are constructed. Knowing these array-functions gives us access to convenience and "cleaner code" when it is appropriate, while loops give us flexibility and optimization when it is required.

One such occassion where we cannot simply choose an array method is when our "set" is indeterminate. For example, above we provided an example where we looped from 1 to Infinity in order to sum values to a certain target. Because you cannot create an array from 1 to Infinity, a loop would be a simple solution to this problem while an array method would not.

While an array from 1 to Infinity is not possible, it should be noted that the problem as stated doesn't strictly require a computation across values from 1 to Infinity, but rather from 1 to an indeterminate end value. A generator function which iterates by one is an available tool that could be used to accomplish this challenge but requiring more language features not discussed in this article.

It is sometimes pointed out that one characteristic of Javascript loops excels over (built-in) array-methods: performance. While this may prove to be a true problem in your usage case, it is important that you verify that this is the source of your issue through measurement before hastily optimizing for this stated-purpose. The tradeoff is "noisier" code which is more difficult to maintain and less pleasant to work with.

If performance turns out to be a true problem, you can also count on the fact that the utility libraries which provide these functions (such as Lodash and Ramda) avoid such criticism. These libraries implement their functions as abstractions over loops with performance optimizations in mind.

Another apparent shortcoming of these array functions is the inability or inflexibility of short-ciruiting (as is available with the break and continue keywords in a loop). It is true that this is not available in the built in array-methods, such as map, filter, and reduce. The consequence of this is that these methods will traverse the entire array, and we may need to add "bypass" code in order to get the intended behaviour.

For example, say that we want to accumulate a list of names in an array of people, but want to stop if the number of results exceeds some value. Two possible options:

const findSomeWithName = (people, name, limit) => 
  people
    .findAll(person => person.name == name)
    .slice(0, limit)

const findSomeWithName2 = (people, name, limit) => 
  people.reduce((acc, person) => {
    if (acc.length >= limit) return acc
    if (person.name == name) return [...acc, person]
    return acc
  }, [])

In both cases, we traverse the entire array, even if we reach our "end condition" very early.

This criticism has a performance aspect and a readability/maintainability aspect. While the performance aspect is something to measure and is discussed above, the second concern isn't easily avoidable using the built in array-methods.

Luckily, by adopting one of the mentioned utility libraries, this too is mostly a non-issue. As has been discussed in other parts of this article, these array-functions are abstractions that can take many forms. These common access patterns result in very particularized array-functions. For example, in Ramda there are reduceWhile, takeWhile, dropWhile variants that allow for tailored logic that halts upon a given condition.

Rewriting the above could look like:

const hasName = (name) => (acc, person) =>
  person.name == name ? [...acc, person] : acc;
const lessThanLimit = (limit) => (accumulator) => accumulator.length < limit;
const findSomeWithName = (people, name, limit) => 
  reduceWhile(lessThanLimit(limit), hasName(name), [], people)
;

If the style of this code looks like Greek to you, you may be interested in my article on Point-Free Style Programming

Abstractions for other types of short-circuiting behaviours can be implemented, derived from combinations of other functions, or will perhaps be included in these popular libraries. Whether you want to go down that path is a matter of preference. Just recognize that this "short-circuiting" behaviour is not an inherent limitation of using array-methods.

Similarly, recursion can tackle the same category of problems as loops and array-functions but (at least in Javascript) suffer from memory-limitations that can crash your program and still require implementing logic manually (unlike using a utility library, such as Lodash or Ramda).

By becoming comfortable in all three approaches to working with collections, Javascript allows you to have a hybrid approach to any given problem that fits your (or your team's) preferred style of coding.

Point-Free Style (in Javascript)

Justin Morgan — Thu, 18 Mar 2021 18:23:35 +0000

All the cool-kids are talking about point-free style. They brag about how clean and declarative their code is and look down at lowly imperative code. You glean that it has something to do with functional programming and clever use of functions as first-class values, but what does it all mean? You don't want to be the last one picked for the coder kick-ball team, do you? So let's dive in and see what it's all about.

In an earlier entry (A Deeper Dive into Function Arity), I alluded to data-last signatures and a point-free style. Although there were occassionally examples, I feel it would be of value to go into greater detail about what these terms mean, and what advantages they afford us. I will not rely too greatly on the contents of that article.

As an introductory definition, point-free style is passing function references as arguments to other functions. A function can be passed as an argument in two ways. Firstly, an anonymous function expression (or declaration) can be provided inline:

    // Function declaration 
    function (arg1, arg2) { ... }
    // Newer (ES2015) style - unnamed function expression
    (value) => { ... }

    // Example
    doSomeThingThatResolvesToPromise
        .then((valueFromPromiseResolution) => {...})
        .catch((errorFromPromiseRejection) => {...})

While this works, it isn't point-free style. A function expression has been declared inline to the function which will consume it. Instead, if we declare our function separately, assign it a name, and provide it by reference to another function:

    function somePromiseValueResolutionHandler(value) { ... }
    function somePromiseValueErrorHandler(error) { ... }
    // Or, using function expressions:
    // const somePromiseValueResolutionHandler = value => {...}
    // const somePromiseValueErrorHandler = error => {...}

    doSomeThingThatResolvesToPromise
        .then(somePromiseValueResolutionHandler)
        .catch(somePromiseValueErrorHandler)

With these examples, you're only seeing the bare minimum requirement of point-free style. A function is being passed by reference as an argument to a function where it expects a callback. The referenced function's signature matches the function signature expected by the callback, and thereby allows us to pass the function reference directly. This allows our function chains to have a lot of noise removed, as functions are not defined inline and the arguments from one function are passed implicitly to the referenced function. Consider:

function someAsynchronousAction(arg1, arg2, (error, successValue) => {...})
// versus
function thenDoTheThing (error, successValue) { ... }
function someAsynchronousAction(arg1, arg2, thenDoTheThing)

At this point, you may be thinking "yeah, that looks a little nicer, but is it really worth the effort?" Broadly speaking, this style of code flourishes when you embrace:

knowledge and patterns of function arity, and
utility functions.

Function Arity Patterns

I have written elsewhere more substantively on the topic of function arity. For the purposes of this discussion, it is sufficient to know that the term arity refers to the number of parameters a function signature contains. Functions can be said to have a strict arity when they have a fixed number of parameters (often given a latin-prefixed name such as unary and binary) or variadic when they can receive a variable number of arguments (such as console.log, which can receive any number of arguments and will log each argument separated by a space).

In Javascript, all functions will behave as variadic functions technically. Although scoped variables can capture argument values in the function signature, any number of arguments are collected in the arguments array-like object (or captured with another name using the rest operator) without any additional steps taken.

function variadicFunction1() {
  console.log("===Arguments Object===");
  Array.from(arguments).forEach((arg) => console.log(arg));
  return null
}
function variadicFunction2(a, b) {
  console.log("===Declared Parameters===");
  console.log(a);
  console.log(b);
  console.log("===Arguments Object===");
  Array.from(arguments).forEach((arg) => console.log(arg));
  return null
}

variadicFunction1("a", "b", "c")
// ===Arguments Object===
// a
// b
// c
// null

variadicFunction2("a", "b", "c")
// ===Declared Parameters===
// a
// b
// ===Arguments Object===
// a
// b
// c
// null

variadicFunction2("a")
// ===Declared Parameters===
// a
// undefined
// ===Arguments Object===
// a
// null

The reason the functions return null is to distinguish the final return of undefined referencing the b argument in variadicFunction2 from the otherwise default undefined return value of the function (which is a void function, i.e. returning undefined as Javascript does by default when no value is explicitly returned).

Related to this point, and essential for the topic at hand, is that in Javascript all function references are technically variadic (i.e. accepting any number of arguments without erroring) though their behaviour remains constrained by however the function signature is defined. That is, we can pass functions by reference as arguments, without writing the execution/assignment of arguments section as so:

function add(a, b) { return a + b }
function subtract(a, b) { return a - b }
function multiply(a, b) { return a * b }
function divide(a, b) { return a / b }

function operation(operator) { 
  // Take all but the first argument
  let implicitArguments = Array.from(arguments).slice(1) 
  // Same thing using rest operator
  // let [operator, ...implicitArguments] = [...arguments] 

  // spread the array arguments into the function execution
  return operator(...implicitArguments) 
}

operation(add, 10, 20)
// operation executes add(10, 20)
// 30
operation(multiply, 10, 20)
// operation executes multiply(10, 20)
// 200
operation(multiply, 10, 20, 40, 50, 20, 50)
// operation executes multiply(10, 20, 40, 50, 20, 50) 
// but the multiply function ignores all 
// but the first two arguments
// 200

This behaviour does pose a challenge, as function arity is not strictly enforced. You can do unusual things and your code will continue to function without erroring. Many developers exploit this characteristic but this requires mentally-retaining more implicit knowledge of the system than if the function arity were explicitly stated and enforced.

An example where this behaviour is exploited is in the Express framework middleware/callback function, which can have multiple signatures. See Express documentation for app.use

// `Express` callback signatures 
(request, response) => {...}
(request, response, next) => {...}
(error, request, response, next) => {...}

// From the Express documentation 
// Error-handling middleware

// Error-handling middleware always takes four arguments. You 
// must provide four arguments to identify it as an error-
// handling middleware function. Even if you don’t need to use 
// the next object, you must specify it to maintain the 
// signature. Otherwise, the next object will be interpreted 
// as regular middleware and will fail to handle errors. For 
// details about error-handling middleware, see: Error handling.

// Define error-handling middleware functions in the same way 
// as other middleware functions, except with four arguments 
// instead of three, specifically with the signature (err, req, res, next)):

Employing this pattern, we can see that we can write our middleware/callback function outside of the site where it will be consumed so long as we match the arity/function signature properly. Refactoring the example from the Express documentation

app.use(function (req, res, next) {
  console.log('Time: %d', Date.now())
  next()
})

// ...can be re-written as 

function logTime(req, res, next) {
  console.log('Time: %d', Date.now())
  next()
}

// ..then hidden away in a supporting file and imported 
// --or hoisted from the bottom of the file-- 
// and passed by reference at the call-site

app.use(logTime)

In currently popular libraries and frameworks such as Express, we implicitly consider the impact of function arity in our code and develop certain patterns that we must become familiar with. Point-free style requires designing with function arity as a central concern.

Data-Last Functions

A pattern that is central to point-free style is that of data-last function signatures. This pattern emerges from the practice of currying a function. A curried function is a function that always takes and applies one argument at a time. Instead of thinking of a function as taking multiple arguments and then producing a single output, we must think of our function as a series of steps before finally arriving at a "final" value.

For example, consider that we are talking about a function which concatonates two strings:

function concat(string1, string2) {
  return string1 + string2
}

The desired behaviour of this function is to take two arguments (both strings) and return a string. This is a functional unit and it may be difficult to conceive of why you would ever need to pause in the middle, but bear with me. To curry this function, we need to allow it to receive each argument one at a time, returning a new function at each step.

function concat(string1) {
  return function (string2) {
    return string1 + string2
  }
}

// or using a cleaner function expression syntax 

const concat = string1 => string2 => string1 + string2

// Executing this function to "completion" now looks like: 
concat("string1")("string2")

It is typical practice to define javascript functions in a non-curried form and to consume functions from external libraries which are provided in a non-curried form. If you wish to use currying in your code, there are curry utility functions in most of the popular functional programming utility libraries such as [Ramda](https://ramdajs.com/docs) and [Lodash/fp](https://github.com/lodash/lodash/wiki/FP-Guide). These utilities simply wrap your existing (non-curried) function and then receive subsequent arguments individually or in groups until all of the required arguments have been supplied. This offers the flexibility of treating functions as truly curried versions or just providing all the necessary arguments as if it were not curried.

Imagine for a moment that you stuck with the original concat function. You are asked to write a function which takes a list of string values and prefixes each with a timestamp.

// ...without currying
function prefixListWithTimestamp(listOfValues) {
  return [...listOfValues].map(value => concat(`${Date.now()}: `, value))
} 

// ...with currying
const prefixListWithTimestamp = map(concat(timestamp()))

Okay, what just happend. I did cheat (a little). We included the map function (rather than use the method on the array prototype) probably from a utility function but we'll write it out below. It behaves in exactly the same way as the prototype method but it is a curried function which obeys the data-last signature.

const map = mappingFunction => array => array.map(value => mappingFunction(value))
// Equivalent to
const map = mappingFunction => array => array.map(mappingFunction)
// Or some iterative implementation, the details of which are unimportant to our main logic

Additionally we created a small utility around our timestamp value to hide the implemenation details.

What is important is that map is a curried function which receives first a mapping function (a function to be applied to each value in an array). Providing the mapping function returns a new function which anticipates an array as its sole argument. So our example follows these steps:


const prefixStringWithTimestamp = value => concat(`${Date.now()}: `)(string) 
// We can pair this down to...
const prefixStringWithTimestamp = concat(`${Date.now()}: `) // a function which expects a string

const mapperOfPrefixes = array => map(prefixStringWithTimestamp)(array) 
// We can pair this down to...
const mapperOfPrefixes = map(prefixStringWithTimestamp) // a function which expects an array of strings
// prefixStringWithTimestamp is functionally equivalent to concat(`${Date.now()}: `)
map(concat(`${Date.now()}: `))

// Perhaps our timestamp implementation can be a utility. 
// We make timestamp a nullary function, `timestamp()`
const timestamp = () => `${Date.now()}: `

map(concat(timestamp())) // A function which expects an array of strings.

This pattern encourages you to design your functions in such a way that the parameters are arranged from least specific to most specific (said another way, from general to concrete). The data-last name implies that your data is the most concrete detail which will be given to the function. This allows for greater function re-use (via function composition) and is necessary to accomplish a point-free style.

Not sure what the proper ordering of parameters is? Don't worry! You will get a feel for it with time. But if you find a function just isn't working, flip it.

const flip = fn => a => b => fn(b)(a)

Utility Functions

Embracing utility functions is critical to realizing the value of point-free style. By doing so, you will realize that a lot of the code you write is a variant of repetitive patterns that are easily generalizable. Additionally it adds a lot of noise to your code.

For example, it is becoming increasingly popular to "destructure" objects and arrays. In many ways, this is an improvement over prior access patterns and itself removes a lot of noise from your logic. If we take that notion a step further, the same can be accomplished by "picking" properties from an object or "taking" from an array.

const obj1 = { a: 1, b: 2, c: 3, d: 4 }

// Destructuring
const {a, c, d} = obj1

// versus "Pick"

// `pick` (from Ramda): Returns a partial copy of an object
// containing only the keys specified.
// If the key does not exist, the property is ignored.

R.pick(["a", "d"], obj1); //=> {a: 1, d: 4}
R.pick(["a", "e", "f"], obj1); //=> {a: 1}

That little definition already exposes a behaviour that isn't matched by the destructuring approach but is critical: pick accounts (in a particular way) for when the property doesn't exist. Say instead you wanted to change the behaviour to such that a default value is supplied if the property doesn't exist on the original object. Suddenly the destructuring approach will get a lot messier. With utility functions (especially pre-written librariers), we can get accustomed to using different utilities that already provide the behaviour we desire while removing this edge case code from our main logic.

const obj1 = { a: 1, b: 2, c: 3, d: 4 }

const {
  a: a = "Nope, no 'a'", 
  c: c = "No 'c' either", 
  e: e = "I'm such a disappointing object"
  } = obj1

// versus

// `pipe` (from Ramda)
// Performs left-to-right function composition. 
// The first argument may have any arity; the remaining arguments must be unary.
// In some libraries this function is named sequence.
// Note: The result of pipe is not automatically curried.
const f = R.pipe(Math.pow, R.negate, R.inc);
f(3, 4); // -(3^4) + 1

// `merge` (from Ramda):
// Create a new object with the own properties 
// of the first object
// merged with the own properties of the second object. 
// If a key exists in both objects, 
// the value from the second object will be used.

R.merge({ name: "fred", age: 10 }, { age: 40 });
//=> { 'name': 'fred', 'age': 40 }

// Our own derivative utility, `pickWithDefaults`
const pickWithDefaults = (keys, defaults) => R.pipe(R.pick(keys), R.merge(defaults));
// Notice: Our data source is omitted, which if included would be written as
const pickWithDefaults = (keys, defaults) => (object) => R.pipe(R.pick(keys), R.merge(defaults))(object);


const defaultValues = { a: "default a", c: "default c", e: "default e" }
pickWithDefaults(["a", "c", "e"], defaultValues)(obj1); //=> { a: 1, c: 3, e: "default e" }

Now imagine that the destructuring approach taken above is employed throughout the codebase, but you don't realize that it contains a bug and this bug emerges only in a subset of the use cases. It would be pretty challenging to do a textual search of the project and modify/correct them. Now instead consider whether our object property access had been done using a function like pick/pickAll. We now have two courses of corrective action.

The first is to "correct" the behaviour in our implementation by implementing our own version, and then update the imports throughout our project to use the fixed version of the function. This is easy because we are simply searching for a reference to the function label (R.pick, or pick in the import section of the project files).

The second, which perhaps we should have considered doing at the outset, is to create a facade for our library. In our utility function, we create delegate functions for the Ramda utilities we use and then we use our delegates throughout the project. Our pick function from our utils file delegates to R.pick. If we decide to move to a different library in the future, "correct" its behaviour, or hand-roll our own versions of these functions, we do so from a single location and our changes propagate to all use-cases.

As an added bonus, extracting utility work out of your main logic allows you to extract that logic right out of the file and into utility files, drastically cleaning up main-logic files. In the example just provided, Ramda provides pipe and merge, meaning they already exist outside of this hypothetical file. Our derivative pickWithDefaults can exist in our own utility file, meaning that only the defaultValues and final pickWithDefaults function execution line are actually in the final code--everything else can be imported. At the very least, utility functions can be moved to a portion of the file that seems appropriate. With function declarations (using the function keyword), the declaration can exist at the bottom of the file and be [hoisted](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting) to the place of execution. Function expressions (using the arrow syntax), sadly, cannot be hoisted and need to be declared above the point of execution.

Without allowing it to overwhelm you, I encourage you to look at the documentation for the function utility library RamdaJS or Lodash. All that I wish to highlight is the abundance of utility functions that these libraries have identified as worthy of inclusion in your aresnal.

Unfortunately, Lodash has two variants--standard and "functional programming"/fp. The fp variant is necessary for what we are discussing here but the main documentation cannot be viewed in the "fp-style" of data-last function style. The biggest difference between the two versions is the order of parameters/arguments is such that the "data being acted on" comes last. The fp-guide does discuss other differences.

Another library that is thematically linked to this topic is RxJS, which is particularly useful for converting "events" (often real-world events) into data. This allows for the normalizing of event-handling in the manner just described. For example, "double-click" can be defined as a utility which is consumed throughout a project in a unified manner. Operators are functions which transform this data and eventually these transformed events are either consumed or ignored.

Conclusion

I genuinely believe that point-free style is a helpful in making my projects' main logic cleaner and more condensed. But this benefit comes at an expense or at least with some cautions.

If working with others who do not use point-free style, it can be jarring if done in excess. In several of the examples above, we created utility functions which omitted the data source (in order to avoid having to create a superfluous wrapping function).

const pickWithDefaults = (keys, defaults) => R.pipe(R.pick(keys), R.merge(defaults));

// Notice: Our data source is omitted, 
// which if included would be written as
const pickWithDefaults = (keys, defaults) => (object) => R.pipe(R.pick(keys), R.merge(defaults))(object);

For your collegues' benefit, consider including the data source for documentation's sake. You would still gain the benefit of deploying it without needing to include it, and so it still has the desired impact.

Similarly, it is possible to chain a tremendous number of utilities together in a single block. There are even utility functions in libraries which replace the typical imperative operators, such as: if, ifElse, tryCatch, forEach, etc. Chaining together too many of these will result in your code looking pretty similar to a block of imperative code. Instead, try to think of functional blocks and define them such that they expose a simple interface. That way, chaining the pieces together documents your intent and reduces the chance that you get lost in your control flow.

While it can seem overwhelming at first, a utility library such as Ramda can be approach incrementally to great effect. Additionally, there are Typescript typings available for Ramda, though the README page does admit that there are certain limitations they have encountered in fully typing the library.

Lastly, as you split up your logic into utilities you are inherently creating abstractions. There is a popular addage within the coding community--AHA (avoid hasty abstractions). To an extent, this can be reduced by standing on the shoulders of existing library authors. The abstractions present libraries such as RamdaJS are not hasty, but rather longstanding ideas battle tested in the fields of functional programming and category theory. But in organizing our code, consider restraining yourself from writing code that doesn't come intuitively. Instead, write some code and then reflect on whether you see opportunities to clean it up. In time you will accumulate wisdom that will guide your future point-free efforts.

A Deeper Dive into Function Arity (With a Focus on Javascript)

Justin Morgan — Mon, 21 Dec 2020 18:37:36 +0000

If you are arriving at this article with any background in one or more of the popular programming languages of the day, you will most likely have at least an implicit understanding of what function arity is. The term arity refers simply to the number of parameters in the definition of a function. This is casually expressed as how many arguments a function takes.

For many, this definition is sufficient. My goal is to convey a deeper understanding of this concept, and to tie it to other programming concepts which you may encounter (here, currying and partial application, but also point-free style).

Arity Definitions

In programming circles where function arity is explicitly discussed, there is a set of related labels which are used to describe different kinds of function arity based on the number of arguments expected by a given function. They are:

Nullary: zero arguments
Unary: one argument
Binary: two arguments
Ternary: three arguments
N-ary: having N arguments
Variadic: having a variable number of arguments

While it is possible that you may encounter specific names for a set of 4 or more arguments, it is uncommon. See the Wikipedia article on the topic for a more elaborate list of names available: Function arity.

Strict Arity Requirements

Some languages, especially those with a functional programming bent, will give more attention to the topic of arity than Javascript typically does. For example in the Elixir language, you must provide precisely the number of arguments equal to the number of parameters in the function definition (except for those with provided default values). This requirement allows for a feature called multiple dispatch, which is to say that a function identifier can have multiple definitions for different function arities (also based on different patterns of arguments provided):

# the `Elixir` notation used is the function_name/arity

# join_strings/2 
def join_strings(list, combinator) do
    Enum.join(list, combinator)
end

# join_strings/3
def join_strings(item1, item2, combinator) do 
    item1 <> combinator <> item2
end

iex> join_strings(["Cat", "Dog", "Ferret", "Monkey", "Parrot"], " & ")
"Cat & Dog & Ferret & Monkey & Parrot"

iex> join_strings("cat", "dog", " & ")                                              
"cat & dog"

iex> join_strings("cat")  
** (CompileError) iex: undefined function join_strings/1

iex> join_strings("cat", "dog", "parrot", "ferret", " & ")  
** (CompileError) iex: undefined function join_strings/5

Contrast this with the design of the Haskell programming language, where all functions are unary (or nonary/no-argument) functions. Here, it is ordinary that a function will be "partially applied", returning another function rather than a "value" or "data".

-- The type signature reflects the unary nature of Haskell functions
add3 :: Number -> Number -> Number -> Number
add3 x y z = x + y + z

a = add3 10 -- `a` is a function y z = 10 + y + z 
b = a 20 -- `b` is a function z = 10 + 20 + z 
c = b 30 -- `c` is now evaluated to 60 (10 + 20 + 30)

But in Javascript, this requirement does not exist. In fact, functions can receive less or more than their "required" arguments and still proceed with execution. If fewer arguments are supplied than the function definition provides parameters for, then the "missing" arguments will be undefined. If more arguments are passed than the definition provides parameters for, the declared and "extra" arguments are available via the reserved arguments array-like object.

function logEmAll(a, b, c) {
    console.log(`a: ${a}`)
    console.log(`b: ${b}`)
    console.log(`c: ${c}`)

    for (let i = 0; i < arguments.length; i++) {
        console.log(`arguments[${i}]: ${arguments[i]}`)
    }
}

> logEmAll(1,2,3,4)
a: 1
b: 2
b: 3
arguments[0]: 1
arguments[1]: 2
arguments[2]: 3
arguments[3]: 4

We can see that if more arguments are passed than are required, the function continues with execution without issue. The "extra" arguments are merely not used (unless accessed via the arguments object explicitly, which we have done in the above example).

In the Node framework, Express, this pattern is employed in the ubiquitous connect-style callback throughout the framework. This results in "shifting" parameters depending on the context:

(request, response, next) => {...} 
(request, response) => {...} // Omits the third `next` parameter when not used
(_request, response, next) => {...} // `_` marks the first parameter as not in use (idiom)
(error, request, response, next) => {...} // "Shifts" the parameters one position
(error, _request, _response, next) => {...} // "Shifts" the parameters one position and skips parameters

One characteristic demonstrated above is that the function definitions rely on positional arguments. That is, the function consumes arguments based on their index in the arguments list. To contrast this, there is an approach of named parameters/arguments. For example, the Koa framework (created by the creators of Express), collapses the arguments of the equivalent callbacks into an object (the "context" object), which contains properties analogous to request, response, next, and error in the above examples.

With named arguments, the idea is that the function arguments are contained as properties on an object. We can mix the positional and named argument approaches, taking some positional arguments and a complex/object argument. This pattern is fairly common, whereby the final argument is an object of configuration options, allowing for the function to determine which options were or were not provided without cluttering up the function signature too much. But at its extreme, a function can be defined as taking one argument (a unary function) that is an object containing multiple pieces of data to be consumed.

function userFactory(userTraits) {...}

// Taking advantage of ES2015 destructuring, the `named` quality is more apparent
function userFactory({name, email, address}){...}

One advantage to this approach is that the order of supplied arguments does not matter. Similarly, if arguments are omitted, the function signature and corresponding call are less noisy.

// Fictitious Express/Koa-like callbacks that support named arguments (mirroring above example)
({request, response}) => {...} 
({next, request, response}) => {...} // Order swapped (for no reason)
({response, next}) => {...} // Request omitted
({request, response, next, error}) => {...} // No more "shifting" params
({error}) => {...} // Request, response, and next parameters omitted

Variadic Functions

That was a brief survey of common treatments of function arity in the Javascript community. But let us consider it differently for a moment. Another way is to think of all functions having a single argument (a unary function) that:

is an array (the arguments array-like object); and
is, as a convenience, destructured in the function signature.

When thought of in this way, we can gleam a better understanding into the idiom employed in ES2015+ whereby a function's arguments are "collected" using the "rest/spread" operator. This has become an increasingly common pattern for implementing variadic functions.

// `pipe` will take any number of arguments (intended to be functions)
// and return a function which receives one argument that will be used
// as the input to the first argument, which will be the input to the
// second argument, which will be...etc

// pipe(f1, f2, f3)(value) --> f3(f2(f1(value)))

function pipe(...fns) {
    return function(input) {
        return fns.reduce((val, fn) => fn(val), input)
    }
}

// Or like this, with the `fns` supplied as an array [fn1, fn2, fn3]
// pipe([f1, f2, f3])(value) --> f3(f2(f1(value)))
function pipe(fns) {
    return function(input) {
        return fns.reduce((val, fn) => fn(val), input)
    }
}

// `pipe` could be rewritten as 
// (highlighting the implicit unary-signature interpretation)
// pipe(f1, f2, f3)(value) --> f3(f2(f1(value)))
function pipe() {
    // Before the inclusion of the rest/spread operator
    // this would be accomplished with a loop acting 
    // on the `arguments` object 
    var [...fns] = arguments
    return function(input) {
        return fns.reduce((val, fn) => fn(val), input)
    }
}

/* 
The above is written as two unary functions to reflect a design common in the JS functional-programming community referred to as "data-last" signatures. This allows for a function to be "partially applied" and to be used in "pipelines" for greater compositional flexibility. 

Additional information on this `data-last` signatures, `currying`, and `point-free style` are provided at the end.
*/

If you are unaware of this behaviour, and how to exploit it, you may find yourself writing more convoluted code than is necessary. For example, you may need to write utilities that behave like variadic functions, but in failing to identify the ability to act on the arguments object directly, you unnecessarily rewrite the same function to support multiple arities.

// `zip` is a common operation upon lists. Traditionally it takes one element from the 
// head of each list and combines them into a new unit.
// ex. (2 lists) zip([1,2,3], ["a", "b", "c"]) --> [[1, "a"], [2, "b"], [3, "c"]] 
// ex. (3 lists) zip([1,2,3], ["a", "b", "c"], ["!", "@", "#"]) --> [[1, "a", "!"], [2, "b", "@"], [3, "c", "#"]] 
function zip2(list1, list2) {...}
function zip3(list1, list2, list3) {...}
function zip4(list1, list2, list3, list4) {...}
function zip(list1, list2, list3, list4) {
    if (!list4 && !list3) { return zip2(list1, list2) } 
    else if (!list3) { return zip3(list1, list2, list3) } 
    else { return zip4(list1, list2, list3, list4) }
}
// Versus
function zip(...lists) { ... }

When you become aware of the nature of Javascript's treatment of arity, you open the door to learning more advanced coding patterns. Two such patterns, popular in the realm of functional programming and increasingly in the Javascript community generally, are partial application and the related concept of currying. These two patterns heavily employ and exploit knowledge of function-arity.

Currying vs Partial Application

When observing currying and partial application in effect, people often. collapse their understanding of one into the other. I believe that part of this misunderstanding stems from the a prevalent notion that functions are not "real values". Put another way, that a function which returns a function "isn't really done yet".

An example. Let's say that we have a collection of users and a function which takes an options argument which describes the behaviour that the filter function will operate.

function filter_users(filter_options, users_collection) { ... }

We may want to particularize this function into a number of other functions.

const filter_params_without_email = {...}
const filter_users_without_emails = filter_users.bind(null, filter_params_without_email)

.bind() is a native Javascript method that all functions "inherit" that:

returns a new function that is a copy of the attached function (here filter_users);
assigns a value to the this keyword in the execution context of the new function (unused in this example); and
"partially applies" arguments to the function when it is called.

In some languages, the bind method would be unnecessary. You would instead call the function with the arguments you have available, they are applied positionally according to whatever rule of the language in question sets, and you get a function in return that is awaiting just the remaining positional arguments.

The point of misunderstanding is in the notation of how Javascript (and many other popular languages) implement functions. As we described above, a Javascript function can be thought of as being a unary function which is provided its argument in an array (technically, an array-like object). And by the syntactic sugar of the language, these arguments have been destructured so as to ease their access within the function body. It would be a similar situation if we adopted the named argument approach using an object rather than an array to store our arguments. Upon receiving it's one and only argument set (positional or named arguments), it attempts to access the specific indices/properties of this argument set immediately. If these are not all provided, you may encounter property access errors for those missing arguments.

What bind is doing is holding onto those initially supplied arguments, holding onto a reference to the original function, and returning a new function for you to use with a remapping of arguments (i.e. the "second" positional argument becomes the "first" positional argument in the new function).

Currying on the other-hand, introduces a different premise. Currying is the whole-hearted embrace of unary (and nullary/no-argument) functions. To "curry a function" is to define it as such that it accepts one argument and
returns either a function or a value. It is possible to curry a function that was not initially defined in such a manner, using the .bind() method described
above or a utility such as the ones provided in the several functional programming libraries (some of which are listed at the end).

A toy example would be addition. A non-curried implementation of addition could look like:

function add(a, b) {
    return a + b
}

To curry this function would be to define it as such:

function add(a) {
    return function (b) {
        return a + b
    }
}

Well that's terrible. Why would we do that? As of ES2015, there is an alternative syntax (with its own quirks, to be sure) for more succinctly representing currying (with arrow function expressions).

const add = (a) => (b) => a + b

Ooh, that's even cleaner than the original. If you'd like to know more about ES2015 "arrow function expressions" you can follow this link to the MDN Web Docs.
What's more is that this silly example can be particularized very easily.

const add2 = add(2) // add2 is now a function // add2(4) --> 6
const add3 = add(3) // add3 is now a function // add3(4) --> 7

To return to the earlier "partial application" example, now curried:

const filter_users = (filter_options) => (users_collection) => { ... }

// filter_users_without_emails will be a fn awaiting data
const filter_users_without_emails = filter_users({...filter_params})

To explain what is happening, it should be highlighted that returning a new function from a function is often very useful. It should not be thought of as a "mid-way point" in execution. By using currying and "partially applied" functions, you can drastically clean up your code.

For example, using the pipe function described above, one can destructure a code block into single purpose functions and then compose them back together, with the function descriptors serving as documentation.


// These functions can be generalized and/or perhaps imported from a utility file
const asyncFunctionReturnsPromiseOfUser = (req) => {...}
const getPostsFromUser = (sortOrder = "desc") => ({id}) {...}
const excludeOlderThan = (oldestDate = "1970-01-01") => (posts) {...}
const includeOnlyWithTags = (tags) => posts => {...}

const getUsersPostsCallback = (req, res) => {
    // `pipe` (and therefore `filterPosts`) returns a function which awaits data, 
    // in this case a list of posts (`data-last` and `point-free` styles)
    const filterPosts = pipe(
            excludeOlderThan(req.params.oldest),
            includeOnlyWithTags(req.params.tags)
        )

    asyncFunctionReturnsPromiseOfUser
        .then(getPostsFromUser("asc")) 
        // `then` has an implicit unary callback with the data from the resolved promise
        // i.e. (user) => {...}
        // `getPostsFromUser("asc") returns a unary function expecting a user
        // and is provided as the callback to `then` 
        // equivalently written as `(user) => getPostsFromuser("asc")(user)`
        .then(filterPosts)
}

If you are interested in exploring the claimed advantages of currying, I recommend exploring the following topics:

Why Curry Helps
Favoring Curry
Data-Last Function Signatures
Point-free Style
- freeCodeCamp Article
- TheEvilSoft YouTube Presentation
Lamda Calculus (Stanford Encyclopedia of
Philosophy)
Functional Programming Libraries
- RamdaJS
- LodashFP
Compile to Javascript languages which embrace functional programming and currying
- Elm
- ReasonML
- PureScript