3 ms·
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
by goldenkey 5y ago
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.
- masklinn 5y agoIt'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.