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

32 comments

#metaprogramming #library #pipeline

1 6464 32

2020-04-29 08:35:13 UTC

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.

Post #11

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #2

josevalim

Creator of Elixir

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.

Post #24

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.

Post #33