3 ms·

> By contrast, currying in languages with Algol-descended syntax always requires more rigamarole. It's possible, of course, in a lot of them, but it's harder th

by adwn 7y ago

> By contrast, currying in languages with Algol-descended syntax always requires more rigamarole. It's possible, of course, in a lot of them, but it's harder than just a function call missing some of its arguments. Really? Given a Python function def divide_by(a, b): return a / b What would be so hard about divided_by_2 = divide_by(, 2) divide_5 = divide_by(5, ) Or, in Rust: fn divide_by(a: f32, b: f32) -> f32 { a / b } // ... let divide_by_2 = divide_by(, 2.0); let divide_5 = divide_by(5.0, ); I can't immediately see any major problems with this. It's basically a closure, after all: let divide_by_2 = |a| divide_by(a, 2.0);

jerf 7y ago
"What would be so hard about divided_by_2 = divide_by(, 2)" Well, first of all, it doesn't work right now, which is a problem for what I was trying to say. Secondly, if you want to curry things, you'll end up with four_arg_func(1, 2)(3)(4) at a bare minimum as a "curried application", where in Haskell it's just four_arg_func 1 2 3 4 Several Algol languages have other issues, such as dealing with optional arguments: in Python!curryable, is the result of def f(a, b, c = 10): return a + b + c f(1, 2) a function that accepts one more parameter for c, or the number 13? (Even in a dynamic language you ought to think twice before trying to return some sort of "quantum superposition" of those two things!) You'll need to add some syntax that will specify the answer to that question, and now Python!curryable is getting away from just "incompletely applying the function" as it is in Haskell, but now a Thing you have to Do. (Probably by calling https://docs.python.org/2/library/functools.html#functools.partial https://docs.python.org/2/library/functools.html#functools.p... .) Haskell hacks that away by making it so functions take a fixed number of parameters, in a fixed order, and there is no such thing as default parameters to a function. A non-Haskell programmer may feel this is not a trade worth making. Your closure at the end is what it tends to really look like. You'll note that most non-functional code doesn't really do that sort of thing very often, unless you're unlucky enough to stumble across a codebase written by someone trying to write Haskell-in-Python or something.

by adwn 7y ago

jerf 7y ago

"What would be so hard about divided_by_2 = divide_by(, 2)" Well, first of all, it doesn't work right now, which is a problem for what I was trying to say. Secondly, if you want to curry things, you'll end up with four_arg_func(1, 2)(3)(4) at a bare minimum as a "curried application", where in Haskell it's just four_arg_func 1 2 3 4 Several Algol languages have other issues, such as dealing with optional arguments: in Python!curryable, is the result of def f(a, b, c = 10): return a + b + c f(1, 2) a function that accepts one more parameter for c, or the number 13? (Even in a dynamic language you ought to think twice before trying to return some sort of "quantum superposition" of those two things!) You'll need to add some syntax that will specify the answer to that question, and now Python!curryable is getting away from just "incompletely applying the function" as it is in Haskell, but now a Thing you have to Do. (Probably by calling https://docs.python.org/2/library/functools.html#functools.partial https://docs.python.org/2/library/functools.html#functools.p... .) Haskell hacks that away by making it so functions take a fixed number of parameters, in a fixed order, and there is no such thing as default parameters to a function. A non-Haskell programmer may feel this is not a trade worth making. Your closure at the end is what it tends to really look like. You'll note that most non-functional code doesn't really do that sort of thing very often, unless you're unlucky enough to stumble across a codebase written by someone trying to write Haskell-in-Python or something.