I definitely see the value of having a new function which helps with piping into anonymous functions. I vote for `Function.into`, it reads nicely and doesn't have the confusion of `pipe_to`.
On Tuesday, August 13, 2019 at 12:12:13 PM UTC-4, José Valim wrote: > > I have just asked to keep this thread on topic. In particular: > > 1. Can we focus on the pros and cons of what was proposed? > > 2. If we are going to propose other alternatives, can they be implemented > using regular functions/macros, and without introducing or re-purposing > existing syntactical constructs? > > As said, most syntactical options have already been discussed extensively > in the past. I am not personally interested in rehashing those arguments. > If someone is interested, please do so in another thread. > > Thank you, > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On Tue, Aug 13, 2019 at 5:42 PM OvermindDL1 <[email protected] > <javascript:>> wrote: > >> On Tuesday, August 13, 2019 at 3:04:03 AM UTC-6, José Valim wrote: >>> >>> 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. >>> >> >> At that point adding in `.()` isn't a big deal, that's why it's pretty >> well fine as it is honestly for those kind of things. >> >> The main issue is just piping into another 'argument' of a function call, >> like the erlang standard library very much expects the 'subject' to be at >> the end, so I end up having to do a lot of things like: >> ``` >> args >> |> transform_them() >> |> (&send(pid, &1)).() >> ``` >> When it would look and feel so much more clean via anything like: >> ``` >> args >> |> transform_them() >> |> &send(pid, &1) # Special case when `&` is in first position, though >> that does run into the expecting passing a `fun` to work >> >> args >> |> transform_them() >> |> send(pid, _) # Pipe into the 'hole' >> >> args >> |> transform_them() >> |> send(pid, _1) # Maybe index it, though this seems entirely needless >> >> args >> |> transform_them() >> |> send(pid, &0) # Or use `&0` as a pipe value, though then it looks less >> like an obvious hole and thus more easy to 'scan' past >> >> args >> |> transform_them() >> ~> send(pid, _) # Perhaps a different pipe operator for piping into, but >> this seems needless when `|>` can do it just fine >> ``` >> >> All of which are much more easily read. And there are libraries for >> doing just this, they 'feel' so much more clean when I use them. With all >> of all of the above no closures even need to be created, it doesn't look >> like an anonymous function (except maybe the `&0` one), the prior value >> is just dumped into 'that' slot instead of the front slot. Honestly I'd >> prefer if it always required `_`, no magic 'stuff into front position' or >> anything, this would even allow you to reference the value more than once >> (set it to a gensym'd name then and put that in the holes). >> >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/0f96553b-4db8-43f3-9565-b7749526c6d5%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/0f96553b-4db8-43f3-9565-b7749526c6d5%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/735b77b7-de51-48c7-8333-6df90529d11d%40googlegroups.com.
