Elixir pipe into operator bug

So I have a ~>/3 operator in scope and am trying to pipe in to it like:

a
|> (b ~> c)

And this works just fine if I build the AST manually (like via {:~>, [], [a, b, c]}) or call it directly (like via Blah.~>(1, 2, 3)), but I keep getting errors like this:

** (ArgumentError) cannot pipe a into 1 ~> 2, the :~> operator can only take two arguments

Which is of course a bit of hogwash since that function/operator can take 3 arguments just fine. Not even using any macro work or anything of the sort in relation to it, just standard function naming since function names can be anything, and the normal built-in pipe operator.

This seems to be an issue with lots of operator-like function names.

This is trivially replicatable via a minimal case like:

iex(1)> defmodule Blah do
...(1)>   def unquote(:~>)(a, b, c), do: a+b+c 
...(1)> end
{:module, Blah,
 <<70, 79, 82, 49, 0, 0, 4, 120, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123,
   0, 0, 0, 14, 11, 69, 108, 105, 120, 105, 114, 46, 66, 108, 97, 104, 8, 95,
   95, 105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:~>, 3}}
iex(2)> 
nil
iex(3)> defmodule BlahTest do
...(3)>   import Blah
...(3)>   def test() do
...(3)>     1
...(3)>     |> (2 ~> 3) # Purely example data
...(3)>   end
...(3)> end
** (ArgumentError) cannot pipe 1 into 2 ~> 3, the :~> operator can only take two arguments
    (elixir) lib/macro.ex:155: Macro.pipe/3 
    (stdlib) lists.erl:1263: :lists.foldl/3
    (elixir) expanding macro: Kernel.|>/2
    iex:7: BlahTest.test/0

It works fine as well if I prefix the module name on it:

defmodule BlahTest do
  import Blah
  def test() do
    1
    |> Blah.~>(2, 3)
  end
end

It just fails if I try to use it directly, like via importing it, which is super weird since operators are just 2-arity functions of special names, but using those names with other arities works just fine otherwise in every-single-case that I can find except for with pipes.

As far as I can see in the code this is an explicit test and failure on the specific ‘operator’ names, but no test on if the operator actually exist with the given higher arity first (it’s just assuming that it doesn’t exist…), but I have no clue why it’s there (no comments as to the reasoning in the source…), this language inconsistency is breaking a DSEL I was trying to build for some math stuff… :frowning:

2 Likes

I suspect this is on purpose based on the warning for using the + operator in a pipeline.

Can you call it normally with 3 args? a ~> b, c

Also, I’d expect the syntax to be:

a
|> ~>(b, c)

When you’re using the parentheses (2 ~> 3), aren’t you overriding the operator precedence? http://erlang.org/doc/reference_manual/expressions.html#parenthesized-expressions

Without the parentheses, the pipe operator macro will expand and take the 2 expressions before/after it resulting in 1 ~> 2.

defmodule Hello do         
  def unquote(:~>)(a, b, c) do
    a + b + c
  end
end

import Hello

Macro.expand((quote do: (1 |> 2 ~> 3)), __ENV__)
{:~>, [], [{:|>, [context: Elixir, import: Kernel], [1, 2]}, 3]}

Sure:

iex(1)> defmodule Blah do
...(1)>   def unquote(:~>)(a, b, c), do: a+b+c 
...(1)> end
{:module, Blah,
 <<70, 79, 82, 49, 0, 0, 4, 76, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123,
   0, 0, 0, 14, 11, 69, 108, 105, 120, 105, 114, 46, 66, 108, 97, 104, 8, 95,
   95, 105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:~>, 3}}
iex(2)> Blah.~>(1, 2, 3)
6
iex(3)> import Blah
Blah
iex(4)> defmodule Testing do
...(4)>   def test() do
...(4)>     import Blah
...(4)>     unquote(:~>)(1, 2, 3)
...(4)>  end
...(4)> end
{:module, Testing,
 <<70, 79, 82, 49, 0, 0, 4, 80, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 141,
   0, 0, 0, 15, 14, 69, 108, 105, 120, 105, 114, 46, 84, 101, 115, 116, 105,
   110, 103, 8, 95, 95, 105, 110, 102, 111, 95, ...>>, {:test, 0}}
iex(5)> Testing.test() 
6

Not in this case because |> is a macro that expands ignoring immediate parenthetical syntax (specifically 2 ~> 3 compiles identically to (2 ~> 3), of which the pipe operator just prepends to prior to the first in the argument list of the function, and the function is just ~>).

Then what you are doing with 1 |> 3 ~> 3 is doing (1 |> 2) ~> 3, which is most definitely not piping a 1 into the function call of ~>(2, 3) but is rather doing ~>(1|>2, 3), and you can’t pipe a 1 into a 2, so that would fail pretty hard. :slight_smile:

Do note, the function ~> is just a normal function, not a macro or anything of the sort, these kind of function names are used in erlang DSEL’s at times when they make sense in the field that they are being used in.