Let me reformulate that, If no capture arguments (i.e.: `&1`, `&2`, etc.) are used in a capture function and the capture function is simply a function call (of the form `&my_function(...)` or `&my_function`, `&1` will automatically be inlined as the first argument of the captured function, thereby removing the need to know arity at compile time.
Meaning (pseudocode warning): &identity == &identity(&1) &role?(:admin) == &role?(&1, :admin) &role?(&2) != &role?(&1, &2) # capture argument, so no inlined first argument If we go in this direction, why not add something like lens, a capture structured like a property access. `&.my_property` could translate to `&(&1.my_property)` ? I think this is an interesting feature proposal, and both changes are backward compatible. On Tuesday, July 2, 2019 at 9:27:52 PM UTC-4, Rich Morin wrote: > > Thanks for all the thoughtful responses. Also, apologies for the > ambiguities and > omissions in my original note. As so often happens, some of the things I > had in > mind didn't make it into my email. (sigh) > > In this note, I'm only considering the case of named functions that are > explicitly > handed other named functions as arguments, via function capture. So, for > example, > we don't have to worry about dealing with variables which are bound to a > function. > > # Inferring arity of captured functions > > When a captured function (&bar) is being used as an argument to another > function > (foo), it may be possible to infer bar's arity. In the case of library > functions, > this information should be available from the function's typespec. For > example, > https://hexdocs.pm/elixir/Enum.html#group_by/3 tells us that key_fun and > value_fun > both have arity 1: > > group_by(enumerable, key_fun, value_fun \\ fn x -> x end) > > group_by(t(), (element() -> any()), (element() -> any())) :: map() > > So, we should be able to write something like this: > > list = ~w{ant buffalo cat dingo} > > list |> Enum.group_by(&String.length) > # %{3 => ["ant", "cat"], 5 => ["dingo"], 7 => ["buffalo"]} > > list |> Enum.group_by(&String.length, &String.first) > # %{3 => ["a", "c"], 5 => ["d"], 7 => ["b"]} > > To clarify my motivation, I'm not trying to save the effort of typing the > arity > information. Rather, I'm trying to cut down on the amount of clutter on > the page > and (perhaps) the effort of reading it. I also want to get the "/1" > syntax out > of the way to allow for the following notion. > > # Adding arguments to captured functions > > Many named functions take multiple arguments, so they can't be used in > function > captures. Allowing arguments could extend their reach and reduce the need > for > special-purpose lambdas. Here is some proposed syntax: > > list = [ > { :status, 2, "This is a minor problem." }, > { :status, 1, "This is a major problem." } > ] > > list |> Enum.sort_by(&elem(1)) > > which could replace complected horrors such as: > > list |> Enum.sort_by(fn {_, x, _} -> x end) > list |> Enum.sort_by(fn x -> elem(x, 1) end) > > https://hexdocs.pm/elixir/Enum.html#sort_by/3 tells us that its mapper > function > needs to have arity 1: "(element() -> mapped_element)". Although we're > using > elem/2, we're also handing it an argument, so the arity math comes out > even... > > -r > > > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/54d0dc1b-241e-4ed0-a76b-b6d8c828e86f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
