What I see as happening is that you are *injecting* an *argument* into a partially applied *function* call. Perhaps a two-word signature with something more explicit makes sense, like Function.inject_arg(arg, callable) .
On Tue, Aug 20, 2019 at 3:01 PM Kelvin Raffael Stinghen < [email protected]> wrote: > Forgot about `into`, IMO it does not describe the action that is being > done, I mean, it's even hard to try to think about an english sentence that > makes sense: "put the `args` `into` the `function`"? > > On Tuesday, August 20, 2019 at 6:59:04 PM UTC-3, Kelvin Raffael Stinghen > wrote: >> >> I'm really liking the proposal too. About the naming problem, my >> considerations: >> >> - I agree with Matt when he says `pipe_to` makes sense, but it feels like >> it describes more of a use case then what the function does >> - `call`, `execute`, `run` and `apply` look like they would take a >> function as the first argument, not the args. You can refer to plain >> english to get my reasoning: "to `call`/`execute`/`run`/`apply` the >> `function` with/to some `args`" >> - `apply` by itself has another downside, because there is already >> `Kernel.apply`, which does basically what we need, but with the reverse >> argument order >> - `send` could generate confusion because there is already `Kernel.send`, >> but so far for me, that's one of the best options >> - `dispatch` is not very commonly used name, but that's not a very strong >> argument IMO, tied with `send` as the best option >> >> So, I'm pro calling it `send` or `dispatch` because they correctly >> describe the function, not just an use case, and they are semantically >> correct: "to `send` or `dispatch` the `args` to the `function`" >> >> Something that came to my mind is that we could have both options: >> `Function.send(args, function)` and `Function.dispatch(first_arg, >> function)`. That way, with `[1, 2] |> Function.send(&Kernel.+/2)`, would be >> possible to add multiple args functions to pipes (not really readable, but >> interesting technique IMO). >> >> WDYT? >> >> On Friday, August 16, 2019 at 12:31:40 PM UTC-3, Matt Baker wrote: >>> >>> I like this proposal. >>> >>> - It doesn't add any new syntax constructs or special cases to the >>> language, correct? I know opinions vary, but I think this is a strength >>> of >>> the proposal. >>> - To me "&1" happens to also serve as a convenient visual indicator >>> of "where the value's gonna go." It's subjective, but for me it's just as >>> effective as the idea of using "_" that some people have mentioned, while >>> not changing or adding to the meaning of "_". >>> - I found it quite intuitive >>> - I also found it more clear than the existing (&foo..).() I see >>> today. I've never written code this way and found it a little odd to read >>> at first, but have since seen in in other code bases. >>> >>> My only quibble is the name. pipe_to makes sense, but it also feels like >>> it describes the use case more than describing what the function does. Am I >>> correct in thinking this simply takes the first argument and passes it to >>> the function capture on the right when it executes it? >>> >>> A few of these have been floated already, but words that come to mind... >>> >>> - Function.call >>> - Function.execute >>> - Function.run >>> - Function.dispatch >>> - Function.apply >>> - Function.send >>> >>> All that said, I'd hate to see naming alone get in the way of the >>> proposal, I'm in favor of it even as is. >>> >>> On Friday, August 9, 2019 at 7:28:25 AM UTC-7, José Valim wrote: >>>> >>>> Hi everyone, >>>> >>>> With the addition of Function.identity/1, I would like to propose >>>> another function to the Function module: pipe_to/2. >>>> >>>> The idea is that instead of: >>>> >>>> "foo >>>> |> String.upcase() >>>> |> (&Regex.scan(~r/foo/, &1)).() >>>> >>>> One can do: >>>> >>>> "foo >>>> |> String.upcase() >>>> |> Function.pipe_to(&Regex.scan(~r/foo/, &1)) >>>> >>>> Or if you import it before: >>>> >>>> "foo >>>> |> String.upcase() >>>> |> pipe_to(&Regex.scan(~r/foo/, &1)) >>>> >>>> While I wouldn't write the "pipe to anonymous" code, I have seen enough >>>> code in the wild that uses it that having a more readable (albeit more >>>> verbose) approach in the language sounds reasonable to me. The >>>> implementation can be inlined by the compiler to avoid the extra dispatch >>>> cost. >>>> >>>> What are your thoughts? If you "pipe to anonymous functions" in your >>>> code today, would you prefer to use the new function? Yes/no? Why? >>>> >>>> Thank you, >>>> >>>> *José Valim* >>>> www.plataformatec.com.br >>>> Skype: jv.ptec >>>> Founder and Director of R&D >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/JVFGZm58Qo0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/83e76b6e-32e1-4d92-8e52-29a218cbba28%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/83e76b6e-32e1-4d92-8e52-29a218cbba28%40googlegroups.com?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/CAD9kT2TzDRkW2SYiEzWTaRPqpgnq6yDcpSG51Ju%3DX2QJY1Ep4A%40mail.gmail.com.
