Article on FP praising Erlang!
Richard A. O'Keefe
Wed Jun 21 01:46:15 CEST 2006
"Yariv Sadan" <yarivvv@REDACTED> wrote:
- Erlang doesn't support currying, does it? Will it ever?
Let's be clear about what we're asking for.
"Currying" is the process of taking a function
f : A x B -> C
and returning a function
f' : A -> B -> C
We can do that right now:
curry2(F) -> fun (A) -> fun (B) -> F(A,B) end end.
curry3(F) -> fun (A) -> fun (B,C) -> F(A,B,C) end end.
curry4(F) -> fun (A) -> fun (B,C,D) -> F(A,B,C,D) end end.
plus(X, Y) -> X + Y.
Now we can write things like
Except we can't. curry(plus)(42) is a syntax error.
I suppose to count as "supporting" currying, Erlang would have to allow this.
So we change that to
F = curry2(plus),
and of course _that_ doesn't work either, because 'plus' is an atom,
not a function. So we see that the way to curry a function in Erlang
F = curry2(fun plus/2),
which is admittedly clumsy, but it does work, so arguably Erlang supports
currying right now, and has ever since funs were introduced.
I would tend to add
curry2(F, A) -> fun (B) -> F(A,B) end.
curry3(F, A) -> fun (B,C) -> F(A,B,C) end.
curry4(F, A) -> fun (B,C,D) -> F(A,B,C,D) end.
and then use
lists:map(curry2(fun plus/2, 42), [1,2,3])
Having used Clean and Haskell, where functions are "born" curried, and
SML, where traditional usage (hard-wired into binary operators) passes
tuples to functions, and Lisp and R, where functions are not generally
unary at all,
I have to say that curried functions work well in a language built from
the ground up for that kind of use, but tend to be clumsy in thought and
in use in other languages. I _could_ write currying functions for R,
but I can't think when I'd ever want to use them, for example. The
"natural" thing to do in languages like Lisp, R, and Erlang, is to
define ad-hoc lambdas (funs) on the few occasions when currying would have
been any use.
More information about the erlang-questions