I trying to wrap my head around functional programming in js.

I understand add(3)(5) would be:

function add(x) {
    return function(y) {
        return x + y;
    };
}

How would I change this function so add(3)(5)(7)(8) returns 23 or add(1)(2)(3) returns 6?

I trying to wrap my head around functional programming in js.

I understand add(3)(5) would be:

function add(x) {
    return function(y) {
        return x + y;
    };
}

How would I change this function so add(3)(5)(7)(8) returns 23 or add(1)(2)(3) returns 6?

• javascript
• functional-programming

• 1 Are you asking for 4-ary and 3-ary functions specifically, or a general n-ary function? – Nathan Tuggy Commented Jul 29, 2015 at 1:19
• "add(3)(5)(7)(8) returns 23 or add(1)(2)(3) returns 6" --- it makes no sense. Even for a weak typed language it makes sense to have a strictly typed interface. In case of add function it should be add :: Number -> Number -> Number – zerkms Commented Jul 29, 2015 at 1:30
• Search for "JavaScript function currying" and you'll find lots of general examples so you don't have to hand-curry all your functions. Or use rambda.js – Mark Bolusmjak Commented Jul 29, 2015 at 1:49
• I'm asking about n-ary. So add(2)(3) and add(2)(3)(4) would use the same function. – wwwuser Commented Jul 29, 2015 at 19:25
• Are you interested in an answer that uses destructuring from ES6 (see destructuring browser patibility)? It seems like you are after a function that returns two variables. A function to continue currying and a number result. – Jeremy Larter Commented Aug 5, 2015 at 18:17

5 Answers 5

you can do something like this.

function add(x) {
  return function(y) {
    if (y) {
      return add(x+y);
    }
    return x;
  };
}

Here, you can call as many times as you want.

add(4)();
add(4)(5)(9)();
add(1)(2)(3)....(n)();

Example link

Without modifying your definition for add, you would need to chain the calls to add to be (add(add(add(3)(5))(7)))(8).

to clarify, this expression breaks down to:

add(3) //returns a function that adds 3
add(3)(5) //returns 8

add(add(3)(5)) // returns a function that adds 8
(add(add(3)(5)))(7) // returns 15

add ((add(add(3)(5)))(7)) //returns function that adds 15
(add(add(add(3)(5))(7)))(8) //returns 23

Breaking it down even further as @zerkms mentioned (and assigning our function definitions to variables) we can see how the chaining of add works:

var add3 = add(3) //returns a function that adds 3
add3(5) //returns 8

var add8 = add(add3(5)) // returns a function that adds 8
add8(7) // returns 15

var add15 = add(add8(7)) //returns function that adds 15
add15(8) //returns 23

By chaining, we are adding on to the result of the previous call to add.

Meaning that if add(3) returns a function that adds 3 and then you add 5 to that number than you can pass that value, 8, into another call to add to make another function that adds 8 to it's argument.

How about:

function add(x) {    
    return function(y) {
        return y == 0 ? 
               x + y :
               add(x + y);
     };
}

add(3)(5)(7)(8)(0) // ==> 23
add(1)(2)(3)(0)    // ==> 6

The trick here is that it knows when to return a function or the answer by the value of the argument. The "stop" value could be anything really but in my example it's 0 which triggers the answer.

TL;DR

A number cannot be invoked as a function. So use the posite pattern and return a function that has an accumulated result at each iteration. Here is one way to implement add from a factory with tests and example usage: http://jsbin./qaqiqu/edit?js,console

Details:

var factory = (function (){
  "use strict";

  var reduceFactory = function (options) {
    var defaultReduce = function (x, y) { return x + y; },//add
        noLog = function () {};

        function store(x) {
          if (options && options.log) {
            options.log(x, options.acc, options);
          }
          options.acc = options.f(options.acc, x);
          store.result = options.acc;
          return store;
        }
        //default options
        options = typeof options !== 'undefined' ? options : {};
        options.f = typeof options.f !== 'undefined' ? options.f : defaultReduce;
        options.acc = typeof options.acc !== 'undefined' ? options.acc : 0;
        options.log = typeof options.log !== 'undefined' ? options.log : noLog;

        return store;
      };

  return reduceFactory;
}());

//example usage
(function (f) {
  var add = f(),
      add1 = f(),
      add2 = f(),
      add3 = f(),
      add4 = f(),
      clear = function(f) {
        return f(-f.result);
      };
  //how to use a single function
  console.log('add(3)(5)(7)(8).result = ' + add(3)(5)(7)(8).result);
  clear(add);
  console.log('add(1)(2)(3).result = ' + add(1)(2)(3).result);

  //how to use factory functions
  console.log('add1(3)(5)(7)(8).result = ' + add1(3)(5)(7)(8).result);
  console.log('add2(1)(2)(3).result = ' + add2(1)(2)(3).result);

  //factory functions can continue to grow as needed  
  add3(3)(5);
  add3(7)(8);
  console.log('add3(3)(5); add3(7)(8); add3.result = ' + add3.result);

  add4(3);
  add4(5);
  add4(7);
  add4(8);
  console.log('add4(3); add4(5); add4(7); add4(8); add4.result = ' + add4.result);

}(factory));

When the add function finally returns a number, then the number cannot be invoked as a function. The normal way around this is to specify how many arguments are required before a number will finally be returned, as suggested in other answers. Some answers suggested a function terminator (0, undefined) as a novel approach, but from the ments, the OP is

"looking for a solution without the need to end with () or (0)"

Using the posite pattern, we can return a function that can also be used as a number by giving it a result property. That way we can keep accumulating the result with an increasing number of function calls. We can use a factory function to create instances of add if we need to do separate additions. Alternatively we can reset a single instance of add to zero when a separate addition is needed.

I have also written a custom set of test assertions with the following passing test cases:

var testCases = [
        {arguments: [0], expectedResult: 0},
        {arguments: [5, 0, 0, 5, 10, -1], expectedResult: 19},
        {arguments: [1], expectedResult: 1},
        {arguments: [1, 2], expectedResult: 3},
        {arguments: [1, 2, 3], expectedResult: 6},
        {arguments: [3, 5, 7, 8], expectedResult: 23},
        {arguments: [3, 4], expectedResult: 7},//{acc: 1000}
        {arguments: [1, 2], expectedResult: 1003, factoryOptions: {acc: 1000}},
        //example tests with logging to debug
        //{arguments: [1, 2], expectedResult: 3, factoryOptions: {f: add, log: addLog}},
        //{arguments: [3, 4], expectedResult: -7, factoryOptions: {f: sub, log: subLog}},
        {arguments: [3, 4], expectedResult: -7, factoryOptions: {f: sub}}
      ]

I have used inversion of control and made the reduce function an optional parameter to the factory. For example, instead of using add you could use sub (i.e. x - y) as demonstrated in the test cases.

Simply put, the title and the body of the question are about different things.

Firstly, functional programming is not about n-ary functions. You can construct the examples shown before, for instance with recursion (to maintain immutability); however, you then sacrifice the totality of the function. For instance, the 0 terminated functions could crash at runtime if you had external parameters that you didn't validate to be as non-zero.

The solution that would enable totality then either accepts non-zero integers (JavaScript only has 'number' type), and gets called with zero to get the value.

Alternatively, a monad could allow you to bine the properties of a number while returning a function that could be bound further. (But then you wouldn't end up with a pure 'number' but rather a custom 'add' monad. Useful, but has to be implemented.)

Otherwise, the add function could just be a sum of a list. Then it can have from 1 to N elements for putation, it just wouldn't be it's arguments.

Now, as to why variable arity is not very functional, the reasons are pretty fundamental. For one, if you had a function f(a)(b)(c)(d)...(n) what is it's type? Without types, you lose many core aspects of the field. If it always returns type of itself (which is possible, shown by the recursive example) then it's useless as it cannot actually generate side effects. Now to make it useful, while maintaining purity, we cannot just constraint the domain (i.e.) with zero, because then we're 'lying', since zero is a part of valid inputs; the result is just not going to be of the same type as the function. Hence, if we we're to make a wrapper function that validated all inputs as non-0 (and ignored the 0's) and after the last member called 0, we're doing the exact same thing as discussed before, simply in a different manner.

For instance, we could have a 'Maybe number' as an input, and when it's not a number, the result gets returned (thus totality but functionality). Or we could have a list, and after the list is over, we're once again 'detecting' a change (in a different place, i.e, seeing if the size of the vector has been exhausted; or if there's no more members in a list.)

Either way this is implemented, it does the same thing. Difference is in usability, number of bugs, readability, maintainability, accepted data types, language, or perspective.

A note on why is this all so plicated: supplying an argument on its own is the exact same thing as calling the function. Thus f(a)(b)(c)(d) has 4 applications, with none of them being 'the last one', they are ordered, but there's no implicit finite boundary. The creation of which again loops back to my previous statement of how this is the same exact problem with different implementations.

All of the solutions follow this pattern in one way or another. Chaining the binary add operation results in a very similar data flow to the recursion; however, the boundary is hard coded. The recursion is similar to the OOP style where the sum is accumulated and can be retrieved at any point. Which is similar to the 'Add' Monad which would contain both the addition function together with the current state, and so essentially the 'next' user after the add function would discard the function and keep the state.

I think the simplest solution in terms of the given problem is: [1,2,3,4,5].reduce( function add(sum, x) {sum+x}, 0)