Yet another pipe to nth argument discussion

Flip is nice when the language has auto partial application (no curry’ing needed), but Elixir does not have that, mostly owing to lacking a typing system, thus flip becomes too difficult to read.

I’m still personally a fan of just placing a _ as a “hole” (both visually and logically) for the pipe to fill, which would allow you to do things like:

something
|> blah(42, _)
|> blorp(_) # I like being explicit, no magical 'place in front' magicalness
|> vwoop.("test", _, "thing", _) # Can even be used multiple times!

But it is a nice obvious hole, both visually (“Oh, this is a piped into!”) and logically (scan the AST for _ and just replace it with a binding to the prior expression, single line of work).

I wonder how hard would it be to build it. Looks great!

Actually I wrote a plugin named pipe_to which makes it possible to specified the position of argument while pipe, but only one argument for now.

Oh there is already a library out somewhere that adds the _ ability to pipes, forgot it’s name, but it’s really really easy to code, let me whip up an untested and probably somehow wrong example in the console:

╰─➤  iex
Erlang/OTP 21 [erts-10.2.1] [source] [64-bit] [smp:6:6] [ds:6:6:10] [async-threads:1] [hipe]

Interactive Elixir (1.8.1) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> defmodule BetterPipe do  
...(1)>   def better_piping(value, call, i) do
...(1)>     # Obviously come up with a better reusable binding name, purely temporary and probably still not scope clean in some cases 
...(1)>     binding = Macro.var(:"$bpb$#{i}", __MODULE__)
...(1)>     {call, n} = Macro.prewalk(call, 0, fn
...(1)>       {:_, _meta, ctx}, n when is_atom(ctx) -> {binding, n + 1}
...(1)>       {:|>, _meta, [v, c]}, n -> {better_piping(v, c, i + 1), n}
...(1)>       ast, n -> {ast, n}
...(1)>     end)
...(1)>     cond do
...(1)>       n == 0 -> Macro.pipe(value, call, 0)
...(1)>       n == 1 -> Macro.prewalk(call, fn ^binding -> value; ast -> ast end)
...(1)>       n -> quote do unquote(binding) = unquote(value); unquote(call) end
...(1)>     end
...(1)>   end
...(1)> 
...(1)>   defmacro value |> call do
...(1)>     BetterPipe.better_piping(value, call, 0)
...(1)>   end
...(1)> 
...(1)>   defmacro __using__(_) do
...(1)>     quote do
...(1)>       import Kernel, except: [|>: 2]
...(1)>       import BetterPipe, only: [|>: 2]
...(1)>     end
...(1)>   end
...(1)> end
{:module, BetterPipe,
 <<70, 79, 82, 49, 0, 0, 11, 108, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 1, 96,
   0, 0, 0, 36, 17, 69, 108, 105, 120, 105, 114, 46, 66, 101, 116, 116, 101,
   114, 80, 105, 112, 101, 8, 95, 95, 105, 110, ...>>, {:__using__, 1}}

And it is thus used as:

iex(2)> use BetterPipe
BetterPipe
iex(3)> "test" |> String.upcase() # Normal style works
"TEST"
iex(4)> "test" |> String.upcase(_) # Or use a hole
"TEST"
iex(5)> "test" |> IO.inspect(_, label: _) # Or use many holes, even inside other expressions
test: "test"
"test"
iex(6)> "test" |> IO.inspect(_, label: _) |> String.upcase(_) |> IO.inspect() |> String.downcase() |> IO.inspect(_, label: _)
test: "test"
"TEST"
test: "test"
"test"
iex(13)> ["1", "22", "333"] |> Enum.find(_, fn v -> v |> Regex.match?(~R/^[\d][\d]$/, _) end) # Recursive is no problem either
"22"

Supports full multi-positioning, etc… They are simple to write (although elixir’s language has fun with corner cases, needs tests!). And it is so much more clear to me, no magical values being stuffed into positions (which is weird in a non-curried language, does it go to the start, end, middle, what?!)!

Ah right, it was your library!

Why only one? And it doesn’t seem to support piping into a structure in an argument either, or just a structure outright?

With mine above for example:

iex(14)> 1 |> %{a: _}
%{a: 1}
iex(15)> [a: 42] |> %{a: _[:a]}
%{a: 42}

It is generic piping into something, not just function calls!

I really should publish this sometime, with tests and all, I keep remaking it almost verbatim every few months… >.>

Thanks for the great tips! And I suddenly realize what does it mean by use two target locations. It doesn’t mean return a curried function, but just replace both of target locations with the same, previous result, right? I’ll find some time to implement these.

Yeah, I have written something similar. One place where I can see it fails is when you pipe to something with a body, for example:

foo
|> case do
  {:ok, a} -> a
  _ -> throw "Invalid call"
end

Yeah, mine is definitely not complete, probably should expand macros and not go into blocks or such, or maybe it should just should use another ‘hole’ like __ or something.

In my experience a fair amount of piping inconveniences occurred when I needed to use some Erlang function (say, crypto:hmac/3) where the data that needs to be piped tends to be at the end of the argument list and thus can end up virtually anywhere. Although there generally aren’t that many functions with 3 or more arguments of course.

Yeah, Erlang is much more usual with the subject being at the ‘end’, Elixir is a weird one with it being at the front, if it matched erlang then ‘most’ of these issues (though still not all) wouldn’t be an issue. ^.^

In Erlang isn’t that consistent in that matter either, ex:

• lists:key* functions use 3rd argument as a “source”, which is normally last, except lists:keyreplace/4
• binary:match/{2,3} uses 1st argument as as “source” and 2nd as a pattern, just like Elixir
• ets:match/{2,3} uses 1st argument as a “source” tab and 2nd as a pattern
• erlang:append/2 uses 1st argument as a “source” and second as a value, just like Elixir’s Tuple.append/2
• maps:merge/2 works like Elixir, but to be consistent with “last argument is source” it should work other way around
• maps:update_with/{2,3} has optional Init argument in the middle, but maps:get/{2,3} has optional argument as a last one

Not to brag about Erlang, but Elixir seems to be more consistent there about position of “source”.