My first interview question to a project on the second day at my new job:
"Implement a sum function that will work like this:
sum(1)(2)(3)(4)...(n)"
I could not answer this or any of the following questions...

@irene yes, JS

Ok so it has to be capable of going forever. But how would it know when it has all the inputs and can start the calculation?

If it was say 3 inputs then the answer would be this:
const sum = x => y => z => x + y + z

You could read all the inputs to a common array and sum them that way to get rid of the x+y+z part but the point of it remains the same. It's lambda calculus basically.
But I can't imagine how you'd write it so it can accept an indefinite amount of inputs.

@jschmold if this works then this is fucking brilliant!

I thought he wanted a recursive function for finding sum!

Is it correct what I understood from the question!?

@jschmold
mmmm
Curry

@jschmold It's still not as stated in the OP. You still need to get the Result property off the function. So by that logic you could just as well construct an object that has a sum method on that, that returns itself. Basically what you're doing.

So I'd still say this thing is unsolvable, you can't make a function that takes an indefinite number of arguments via lambdas and returns the result in the end since the function has no way to differentiate if it should return another lambda or the result at any given step.

Basically, give me the number of arguments I need to take or let me call something else to retrieve the result else the thing is unsolvable.

Is valueOf what you're looking for?

@jschmold Yes, you can. But how would you get the value out in the same manner?

I suppose you could assume that the example describes only the calculation phase and bit the retrieval phase, in that case your example is perfectly valid. I assumed it to be sort of self contained in that both execution and retrieval must be done within the same line, as in the example. In that case it would be unsolvable unless I'm missing something.

@jschmold Yea...

But your solution is pretty good, I like it. It's more of the OOP JS sort and while I'm more of a functional JS guy myself, I can appreciate the elegance in it

@jschmold this does seem to work:
function Sum(num) {
this.Result = this.Result || 0;
this.Result += num;
this.Sum = Sum;
this.Sum.Result = this.Result;
this.Sum.valueOf = function(){
return this.Result;
}
return this.Sum;
}

--> returns a Function, but whenever you try to use it as a primitive, it will act as if it was a number:, e.g.

Sum(1)(2)(3)(4) * 1
> 10

@jschmold I wouldn't call what you were doing currying per se. What you're doing is pretty object oriented since it uses "this" and has an internal state. Basically you're creating an object that has a method and a property and then calling that method.

@irene Ye but I've always thought of currying as a thing that uses closures not an internal state on the object. I guess it's a tomato/tomato thing.