> When a captured function is being used as an argument, it may be possible > to infer its arity. So, maybe we can leave this out: > Enum.sort_by(&String.downcase)
How would Elixir know if you meant downcase/1 or downcase/2 on functions like Enum.group_by which accept multiple arities? We would either need a type system or currying (too expensive at runtime on the BEAM) or closures with multiple arities (not available today) or a combination of those for it to work reliably and without surprises. For example, if I write this: fun = get_me_some_function() Enum.sort_by(fun) If get_me_some_function() returns &String.downcase, how would we know which one to invoke? Don't get me wrong, I would love this feature. I love that in Clojure I can do this: (reduce + coll) and they call +/0 for the initial accumulator and +/2 on the reducing. But making this actually work in Elixir is way beyond "simple extensions". > Many named functions take multiple arguments, so they can't be used in > function captures. Allowing arguments could extend their reach: > Enum.sort_by(&elem(1)) And how would I know if you meant &elem(&1, 1) or &elem(1, &1)? Maybe you could say "the first element has to be a tuple and we are passing an integer". But what if we have this: x = result_from_another_function() Enum.sort_by(&elem(x)) Now we don't know either the value of x nor the value being sorted on. You could also say "we will always pass it as first argument". But if you have both fun/1 and fun/2, how do you know if: &fun(1) Means "fn x -> fun(x, 1) end" or "fn -> fun(1) end"? Those features may introduce a bunch of ambiguity once you consider them within the whole context of the language. And we definitely don't want to introduce something that works on very specific cases to save on typing 2 characters. > On a loosely related note, Clojure gets a lot of mileage out of some > higher-order abstractions (eg, seqs). There may be opportunities for > Elixir to follow their lead. For example, some Enum and List functions > might be applicable to Tuples. Similarly, String functions such as > downcase/1 could be extended to accept atoms, etc. Enumerable is Elixir's "equivalent" to seqs. It works with a huge variety of data types and it can be extended. But it doesn't work with tuples on purpose: tuples are not meant to be enumerated. If you are thinking about enumerating tuples, you should most likely rethink how you are using them. And in many cases, yes, we could make the code more generic. We could automatically cast atoms to strings in the String module. But the more generic the code is, the harder it becomes to understand what it is doing. Being able to write assertive code is important for readability. At least for me. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Jul 2, 2019 at 7:19 PM Louis Pilfold <[email protected]> wrote: > Hiya > > Given Elixir has very limited ability to infer information at compile time > how will the compiler know which function to capture? It is not possible to > create a multiple-arity anonymous function on the BEAM. > > Cheers, > Louis > > > On Tue, 2 Jul 2019, 17:52 Rich Morin, <[email protected]> wrote: > >> I enjoyed reading "[elixir-core:8881] [Proposal] identity function" and >> the >> ensuing discussion. It strikes me that some simple extensions to Elixir's >> function capture syntax might: >> >> - clean up the appearance of function captures >> - make existing functions more generally useful >> - reduce the need for special-purpose lambdas >> >> When a captured function is being used as an argument, it may be possible >> to infer its arity. So, maybe we can leave this out: >> >> Enum.map(&id) >> Enum.sort_by(&String.downcase) >> >> Many named functions take multiple arguments, so they can't be used in >> function captures. Allowing arguments could extend their reach: >> >> Enum.sort_by(&elem(1)) # sort by the 2nd element >> Enum.map(&Tuple.append(42)) # append 42 to each tuple >> >> On a loosely related note, Clojure gets a lot of mileage out of some >> higher-order abstractions (eg, seqs). There may be opportunities for >> Elixir to follow their lead. For example, some Enum and List functions >> might be applicable to Tuples. Similarly, String functions such as >> downcase/1 could be extended to accept atoms, etc. >> >> (ducks) >> >> -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/3A20E4BD-9648-4872-852A-C5FFDD0A31D5%40gmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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/CABu8xFAw8okEXjoPkEko1kpy2t6FCv%2BSrGsagxNVARHjFHPSfA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFAw8okEXjoPkEko1kpy2t6FCv%2BSrGsagxNVARHjFHPSfA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGnRm4JhT3vsVPMR9wsvGEG1LxFhFuKi9ZuJTvb_hw480XUOzQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
