Going on that route though, it is weird when compared to the vast variety of languages that had pipes before elixir though. Still though, it's not easy to change the current pattern without either lots of case's being generated in the backend or for the language to get a somewhat half decent type system.
On Wed, Apr 18, 2018, 06:27 Louis Pilfold <[email protected]> wrote: > It's not that weird when you think about it in terms of the AST that the > macro operates on, and not in terms of types. > > The former would require rewriting the forms into anon function calls, > while the latter just prepends a value onto the argument list. `|>` is a > very very simple macro that can be implemented in a single line. There's a > bunch of friendly error handling in the one in Kernel, but it's still just > as simple. > > Cheers, > Louis > > On Wed, 18 Apr 2018 at 11:36 Dylan Johnston <[email protected]> > wrote: > >> Sorry to dredge up an old thread but I wanted to push back against this >>> again. The point of the pipe operator is to be able to clearly express the >>> flow of data through a transformation. Claiming the pipe operator shouldn't >>> be able to handle captured or anonymous functions because it confuses how >>> it works is confusing an implementation detail of how the pipe operator >>> macro works now to how it is semantically expected to behave. Having to >>> wrap them in parenthesis and an invocation introduces a great deal of noise >>> to what could be an extremely simple syntax. As Wojtek Mach showed, it's >>> fairly easy to get the pipe operator to handle these cases, especially >>> since you're pattern matching against them anyway to give error messages. >>> Why pattern match only to give an error when it's easy and straightforward >>> to just make it work, what else could a user intend other than to call the >>> function?. There's a pull request here I made than extends his work so that >>> captured functions and anonymous functions both work. >>> https://github.com/wojtekmach/pipe_capture/pull/1 >>> >> >> "Hello" >> |> fn x -> IO.puts x end >> |> &IO.puts/1 >> |> &IO.puts(:stderr, &1) >> >> vs >> >> "Hello" >> |> (fn x -> IO.puts x; x end).() >> |> (&IO.puts/1).() >> |> (&IO.puts(:stderr, &1)).() >> >> It seems weird to me that the pipe macro works exclusively on already >> invoked functions and doesn't know what to do with a function reference. >> >> -- >> 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/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.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/CABu8xFDB7oMcaXNfrYbkh%3DrLz7YcZMRzcuODjHWaJKp5DkNxZw%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDB7oMcaXNfrYbkh%3DrLz7YcZMRzcuODjHWaJKp5DkNxZw%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/CAJhqboGLoxbiLOog_OokSing%2B6VRdF9thzYKEQmF034i1HwgJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
