Currying vs. Partial Application (2015)
datchley.name
Currying vs. Partial Application (2015)
1–10 of 54 posts
Re: Currying vs. Partial Application (2015)
#2Currying in JavaScript is really nice if you can remember the arities of each curried function you're using. If you forget to call up to the last argument, you'll be passing a curried function instead of the expected value, and it can throw an error really far away from the bug. And instead of normal data to inspect at the error site to point you to the bad call, you'll only have a generic function name to look at. I've spent more hours than I'd like to admit debugging these situations.
A type system would detect these cases, but TypeScript and Flow don't have great support for curried functions. Typing them is very verbose.
Re: Currying vs. Partial Application (2015)
#3I love how the new arrow syntax makes curried functions incredibly simple.
const fn = a => b => c => {
return a + b + c;
};Re: Currying vs. Partial Application (2015)
#4I wrote my own curry using the pareto principle - this works for 80% of my use cases (or more):
const curry = (fn,b) => (a) => fn(a,b);Re: Currying vs. Partial Application (2015)
#5I love how the new arrow syntax makes curried functions incredibly simple. const fn = a => b => c => { return a + b + c; };
appear incredibly simple*️
Re: Currying vs. Partial Application (2015)
#6Currying in JavaScript is really nice if you can remember the arities of each curried function you're using. If you forget to call up to the last argument, you'll be passing a curried function instead of the expected value, and it can throw an error really far away from the bug. And instead of normal data to inspect at the error site to point you to the bad call, you'll only have a generic function name to look at. I…
The type of a curried function in Typescript is just something like:
(a: number) => (b: number) => (c: number) => number
Re: Currying vs. Partial Application (2015)
#7Currying in JavaScript is really nice if you can remember the arities of each curried function you're using. If you forget to call up to the last argument, you'll be passing a curried function instead of the expected value, and it can throw an error really far away from the bug. And instead of normal data to inspect at the error site to point you to the bad call, you'll only have a generic function name to look at. I…
The type of a curried function in Typescript is just something like: (a: number) => (b: number) => (c: number) => number Sure, the parameter names and parentheses are a bit annoying, but I wouldn't call that "very verbose". Comparable concepts in C++ or Java would be a nightmare to type out.
I agree, that doesn't look bad. However, this type definition forces you to supply one argument per function call, which looks awful in JavaScript:
fn(1)(2)(3)
fn(1, 2, 3) === fn(1, 2)(3) === fn(1)(2, 3)
Re: Currying vs. Partial Application (2015)
#8It surprises me to no end that programming languages that promote a functional style with higher order functions do not support partial application as a part of the standard library. It covers 95% of the uses of curried procedures and gives you compiler warnings if you pass too few or too many arguments.
In scheme we have the cut macro that all self-respecting implementations provide which guarantees you zero runtime overhead.
Re: Currying vs. Partial Application (2015)
#9It surprises me to no end that programming languages that promote a functional style with higher order functions do not support partial application as a part of the standard library. It covers 95% of the uses of curried procedures and gives you compiler warnings if you pass too few or too many arguments. In scheme we have the cut macro that all self-respecting implementations provide which guarantees you zero runtime…
Here's an interesting post about the challenges of currying syntax in new languages:
https://github.com/apple/swift-evolution/blob/master/proposa...
Re: Currying vs. Partial Application (2015)
#10I wrote my own curry using the pareto principle - this works for 80% of my use cases (or more): const curry = (fn,b) => (a) => fn(a,b);
Are you typically not binding the first parameter? Why?