> Neither currying nor partial application delay running of the function once all parameters have been passed.

Currying does not, partial application can (and should).

> sum = curry((a,b,c) => a+b+c)

> sum(1)(2)(3) equals 6 under currying.

> sum(1,2)(3) equals 6 under partial application.

Sure. Now what happens to `sum(1, 2, 3)`? Or if the function is `(a, b, c=1) => a + b + c`?

> Perhaps you are thinking of calling the function with no arguments as a signal to execute the final calculation. That is NOT how currying normally works.

Which is the point. It's not how currying works. It is, however, how a "regular" version of partial application works e.g. Javascript's Function#bind or Python's `functools.partial`.

> I believe you are confused.

Nope.

> I believe you think currying works like this:

No.

> The implementation I provided is defacto currying by the book.

"Currying by the book" does is defined for strict arities and can not generate variable-arity functions.

Thank you for helping me understand the issue with default parameter values in a variadic language like JS, which probably makes a nonstandard currying with an execution signal more applicable.

I've created a curry which will only execute when called with no arguments, ie. sum(1)(2)(3)() = 6

This is like you mentioned, a much better suited technique of currying for a language like JS:

  const curry = fn => {
    const curried = (a,...x) => x.length === 0 ? fn(...a) : curried.bind(undefined, [...a, x[0]])
    return curried.bind(undefined, [])
  }

  // equals 15 because default c=10
  curry((a,b,c=10)=>a+b+c)(2)(3)()

We can also apply the same idea of an empty call as a signal to the multi-argument currying variation. I'd love to know what you think. And please keep reading. Because I apologize and stand corrected. Apparently partial application is single use, unlike currying. Essentially a fixed point. I have learned something today. I apologize for being so hard headed. Thank you for putting up with me and correcting me. The wikipedia article on currying confused me with regard to partial application but then I read the partial application wiki article and what you are saying clicked.

It seems like there are 3 techniques here.

Multi argument currying. Single argument currying. And partial application (aka binding)

And too many references called the former the latter, hence my confusion.

It's really no worries. At the end of the day, the issue is really that mathematical / functional / "traditional" currying is not really suited to imperative languages, which is most of them, and notions of "advanced" currying are — I think — throwing good money after bad.

Partial application is very useful (and you're correct that it's "one shot", though you can obviously layer partial applications by partially applying the result), so can the odd curried version of a library function (ideally provided by the library) be, but general-purpose currying… not so much I would say: the languages don't care for it (unlike curried language), it interacts badly with complicated parameterisation (varargs, default, keyword, …), and the almost entirely of the use cases is covered by straight partial application. What little is left can simply be curried by hand.