[Proposal] Support function captures without the need for any argument

[Mário Guimarães]

Hello,

Elixir could support function captures without the need for any argument, so that of instead of writing

 

fn () -> M.fun("value")

end one could write

 

&M.fun("value")

Today the later returns an error like

** (CompileError) iex:28: invalid args for &, expected an expression in the format of &Mod.fun/arity, &local/arity or a capture containing at least one argument as &1, got: M.fun("value"))

Thanks

Mário 

[Mário Guimarães]

Where is 

fn () -> M.fun("value")

it should be

fn () -> M.fun("value") end

or

fn -> M.fun("value") end

[Andrea Leopardi]

Hey Mario,

The capture operator today already has a few forms (arity or arguments) and I think it would be better to keep it simple and not add more specific behaviors, especially considering this would be done to save just a handful of characters. 

Andrea

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a8c88a03-3a3a-4161-bbe4-52f24e1592e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrea Leopardi

an.le...@gmail.com

[José Valim]

Furthermore there are intrinsic ambiguities:

For example:

&1

Is that a function that returns 1 or is it a user error which forgot the outermost &?

And this example:

&num/2

Is that num divided by 2 or an attempt to capture the num function of arity 2?

So the reason why the capture operator requires at least one (consecutive) argument is to make the code clearer. And sure, the compiler could solve those, but the ambiguity will always be there for users reading the code.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BKJDRioz6hpw5-_ByvTNeTd8X-ecMFFXJyJrSsnzi4PXQ%40mail.gmail.com.

[Mário Guimarães]

My comments

sexta-feira, 15 de Fevereiro de 2019 às 11:10:18 UTC, José Valim escreveu:

Furthermore there are intrinsic ambiguities:

For example:

&1

Is that a function that returns 1 or is it a user error which forgot the outermost &?

Yep it is.

 

And this example:

&num/2

Is that num divided by 2 or an attempt to capture the num function of arity 2?

Did not thought about this one ... the only way I see right now would be to use `&num:2` to capture the num function of arity 2.

I suppose there were some reason to choose the `/` char for expressing arity in captures, instead of using the `:` char.

 

So the reason why the capture operator requires at least one (consecutive) argument is to make the code clearer. And sure, the compiler could solve those, but the ambiguity will always be there for users reading the code.

Too late for any change I believe.

Thanks

Mário

[Dmitry Belyaev]

I think of & as those in that order of preference:
&<identifier>/<integer> - local function reference
&<simple-expression> - lambda definition
where <simple-expression> : <function-call> | <literal> | (<complex-expression>)

So
&1 = fn -> 1 end
&num/2 = fn a, b -> num(a, b) end

And of course we don't need even the existing syntax as "this would be done to save just a handful of characters".

--
Kind regards,
Dmitry Belyaev