I really want to avoid new syntactical constructs or special casing anonymous functions as I believe it will be more confusing in the long term.
Imagine we can write this: def find_foos(string) do string |> String.upcase() |> &Regex.scan(~r/foo/, &1) end Then if I have experience with other functional programming languages, I would expect to be able to write this: def find_foos(string) do fun = &Regex.scan(~r/foo/, &1) string |> String.upcase() |> fun end But that won't work, it has to be "fun.()". So I think we need to work consistently with calls. Allowing something that is not a call will be confusing. The other thing is that other proposals raised here (|2>, using _, etc) have already been discussed in the past and they have all been rejected. My position regarding those proposals have not changed. My intent was to bring a *new proposal* but it seems we won't have an agreement either. In any case, we should probably focus this thread on what is being currently proposed instead of bringing previous proposals back to life. :) Regarding the name, one alternative I could come up with was "Function.into/2": string |> String.upcase() |> Function.into(&Regex.scan(~r/foo/, &1)) But it may read like the first argument is an anonymous function (especially if compared to Enumerable.into/2). The other option is Function.thread/2. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Aug 13, 2019 at 10:26 AM Wiebe-Marten Wijnja <[email protected]> wrote: > I have a slightly different proposal: Why not allow `|> > &Regex.scan(~r/foo/ &1)` directly? > > > The mentioned names for the 'wrapper macro that abstracts away the > anonymous function application syntax' have all been names for things that > already exist: > > - `Function.pipe_to` is confusing because using `|>` already pipes > something to something else. > - `Function.apply` is confusing because `Kernel.apply` already exists and > its functionality sort of overlaps with it. > - `Function.capture` is confusing because the `&(&1)` syntax is known as > 'capture operator' or 'shorthand capture syntax'. > > I agree that there are many instances where it makes sense to encapsulate > work in a separatly named function rather than piping through an anonymous > function. > However, in examples such as the mentioned one, where it is only the order > of the parameters that is sub-optimal (and when we remain at the same level > of abstraction(!)), I find > > this: > > def find_foos(string) do > string > |> String.upcase() > |> &Regex.scan(~r/foo/, &1) > end > > > preferable over this: > > def find_foos(string) do > string > |> String.upcase() > |> do_find_foos() > end > > def do_find_foos(str) > Regex.scan(~r/foo/, str) > end > > --- > > I believe implementing this would be rather straightforward, since we only > have to look at occurrences of the `&` operator inside the (top-level) > macro expansion of `|>` (i.e. all magic occurs and disappears at macro > expansion time). > > ~Marten/Qqwy > > -- > 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/e19a826f-dd41-29fb-4ce0-723e1ef25374%40resilia.nl > <https://groups.google.com/d/msgid/elixir-lang-core/e19a826f-dd41-29fb-4ce0-723e1ef25374%40resilia.nl?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4KS7YpEBLTDcB%3DV0a1rLQ_D7arOjSe1stCkM-n6PVthew%40mail.gmail.com.
