Also, these should also work: &String.downcase == &String.downcase(&1) &callback.() == &callback.(&1) &role?(role) == &role?(&1, role)
On Wednesday, July 3, 2019 at 8:45:35 AM UTC-4, Alexis Brodeur wrote: > > 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/8023a90e-97e8-4863-8d70-5859380772f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
