[erlang-questions] Funargs: Ruby-like blocks for Erlang
Thu Jul 21 10:58:29 CEST 2011
On Thu, Jul 21, 2011 at 09:39, Tony Arcieri <tony.arcieri@REDACTED> wrote:
> There's lots of cases where you just want to pass a single fun as an
> argument to a function. By convention this fun is typically passed as
> the first argument. However, the problem with Erlang's fun syntax is,
> well, it isn't fun. It's kind of noisy, and passing a fun as an
> argument makes it even noisier.
> Ruby has this really nifty feature called blocks which, to put not too
> fine a point on it, provides some awesome syntactic sugar for passing
> an anonymous function as an argument to another function.
I think it is useful to investigate this area. The verbosity of
function definitions is not pleasant, but I would argue that it is
mostly necessary (give or take a few tokens). The reason for that is
that we also have guards and multiple clauses. Your new syntax helps
for the simple cases, but the general case won't be much less verbose
than the current syntax. Or at least I can't see how it could be
simplified, maybe you can. An argument can be made that the simple
cases should be easier to type and read, but then there are two ways
to express the same thing. Also, if a code modification leads to the
function being no longer a 'simple case', then the whole expression
needs to be rewritten to use the full syntax.
How do you handle guards and multiple clauses in Reia?
One could just as well instead of "do |X, Y|" write "fun (X, Y) ->"
and keep the existing syntax for the fun. This will allow guards and
multiple clauses. In that case, the proposed change will be that we
Mod:Fun(Arg1, Arg2) fun(X) -> foo(X) end,
Mod:Fun(Arg1, Arg2, fun(X) -> foo(X) end),
which is not really a big difference...
For your XML builder example, the lack of parentheses is the most
compelling advantage, in my opinion. Having "do |X, Y|" instead of
"fun (X, Y) ->" doesn't feel like a big deal. I'm not sure the "less
parentheses" argument is enough - there are other aspects with Erlang
that make in-language DSLs a less than pretty sight.
More information about the erlang-questions