I might be misunderstanding your point about arity-related errors, but every function in JavaScript is variadic, i.e., you can pass any number of arguments to any function and JavaScript will happily call it. Excess arguments vanish into the aether and un-supplied arguments arrive with a value of "undefined". So, to the extent that what you describe is a problem, it's a problem baked into the foundation of the language. :D

The OP is already using Function.length (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), so I suppose one could roll their own arity-checking. It'd be a little out of sync with the rest of the language, though.

While I've not messed with currying in JS, I can see a difference still.

If you have an uncurried function for which you have not supplied sufficient arguments, and it is eagerly evaluated, you more likely see below the call site an error in the function where an expected value is undefined. If the function is curried, the meat of the function remains unevaluated, and so is sure to give you back a value that isn't the one you want. So it does seem like moving to currying in JS is likely to sometimes increase error-to-symptom distance.

Obviously the solution as proposed only allows for non-variadic functions to be curried (where 'non-variadic' means that the function needs to be called with a fixed number of arguments to work correctly, not that it can't be called with the wrong number of arguments, because clearly Javascript doesn't care).

Does currying even make sense for variadic functions? I can't imagine what that would look like as an implementation.

Its possible to curry a variadic function if there is a way to know when you reached the last argument. For example, in a printf-like function you know the number of inputs once you parse the format string.

This example here is a function that sums a variadic list of non-zero numbers. The zero signals the end of the list.

http://pastebin.com/xQRbRcJe

Its certainly very weird though. I wouldn't recommend doing this in real programs.

Perhaps this method could be used by a strongly-typed compile-to-js curried language. (PureScript, Elm, and friends)

I haven't used either but since they're based on Haskell I would assume that currying is inherent to the language (functions are curried by default).

Hence a "curried language".

Yeah, but a technique like this just isn't useful there. The host language handles when function application occurs.

No, curried languages compiled output typically has tricks like in the OP and they typically rely on a run time system to help with the 'impedance mismatch' between curried and not languages.