cjen07
ParamPipe - parameterized pipe in Elixir
parameterized pipe in elixir: |n>
edit: negative index in |n> and mixed usage with |> are supported
example:
use ParamPipe
def foo(a, b, c) do
a*2 + b*3 + c*4
end
def bar0() do
100 |> div(5) |> div(2) # 10
end
# negative n in |n> is supported
def bar1() do
1 |0> foo(0, 0) |1> foo(0, 0) |-1> foo(0, 0) # 24
end
# mixed usage with |> is supported
def bar2() do
1
|> foo(0, 0) # 2
|1> foo(0, 0) # 6
|> div(2) # 3
|> div(3) # 1
|2> foo(0, 0) # 4
|> (fn x -> foo(0, 0, x) end).() # 16
|-1> foo(0, 0) # 64
end
code: GitHub - cjen07/param_pipe: parameterized pipe in elixir: |n> · GitHub
what do you think of this? ![]()
previous tricks: 3 meta-programming demos: prefix, memorization, julia port
Most Liked
OvermindDL1
If I were to do something like this I’d have the syntax as something like:
1
|> foo(0, 0) # 2
|> foo(0, &_, 0) # 6
|> div(2) # 3
|> div(3) # 1
|> foo(0, 0, &_) # 4
|> (fn x -> foo(0, 0, x) end).() # 16
|> foo(&_, 0, 0) # 32
Which is valid syntax and is syntax I’ve made but I don’t use since it is not ‘standard’ anyway, plus it is not that hard to just do 1 |> (&foo(0, &1, 0)).() or so, as ugly as it is. Maybe just a helper macro to re-shuffle args or so would be cleaner or something.
Honestly, if I were to buff pipe, adding some ‘put in this place here’ would be nice, but I’d prefer something of a more monad’y composition as error handling then would become so much easier.
benwilson512
It is difficult to exaggerate how much discussion has been had with respect to modifying the pipe operator. The consensus response is pretty negative to such modifications, and to be honest this is a great example why.
1
|0> foo(0, 0)
|1> foo(0, 0)
|2> foo(0, 0)
This is completely indecipherable. Obviously the foo function name doesn’t help, but the whole point of the pipe operator is that there is a consistent view on what constitutes the primary noun for each function.
josevalim
I think there is some confusion between readability and familiarity. Of course a construct someone is not familiar will be unreadable to most.
The trouble with this proposal is that it puts the burden on reading code even when I am familiar with the construct, the pipe operator. When I read the examples above, I need to manually unwind the operator and place the argument on where it needs to be. It prioritizes writing code over reading code and that’s a trade-off I would hardly make.
Every time I want to pipe to another argument, I write a private function and give it a decent name. No shortcuts. And the final code will read better too.
Last Post!
stefanchrobot
Frankly speaking, I find the parametrized pipe hard to read and understand, so I don’t really have an intention to use the library. Having said that, I applaud your persistence and I’m very happy that Elixir allows you to even do these things!
On a side note, I think an explicitly “indexed” pipe would gain my interest (I’m looking at you File.write). Something like:
data
|> foo(1, 2) # pipe into the first argument
|>> bar(4, _, 6) # pipe into the second
So the idea is here that there’s a new operator and I can explicitly state which argument I want to pipe into. The |>> is far from perfect, since it breaks the alignment.
Popular in Announcing
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










