The first rule of macros is that the accept AST and they must return AST. The way this is typically accomplished is to wrap the code you want executed at runtime in a quote expression. For example:

defmacro b(arg) do
  quote do
    unquote(arg)
    |> String.split("\n")
    |> IO.inspect()
  end
end

Note that in order to apply the arg inside the quoted expression, it needs to be unquoted.

It is called - there other(&b/1). Macros aren’t (at least directly) available in runtime, so cannot be referenced. So what Elixir does is that it treat it the same way as fn a -> b(a) end, which mean it need to expand b(a) call. And there is where your code is evaluated.

There are at least two things going wrong here:

1. @hauleth is absolutely right, the &b/1 is being rewritten to fn x1 -> b(x1) end. The macro b then expands with the argument x1, which is {:x1, [], :elixir_fn} as AST. This is why you see the {:x1, [], :elixir_fn} being passed to String.split/3 in your example.

2. Even if you rewrite the body of a to handle a non-string argument, e.g. ignore the argument completely and just return :ok, returning the anonymous function fn x1 -> b(x1) end from b is invalid:

   ** (CompileError) scratch.exs: invalid quoted expression: #Function<0.1526323/1 in Foobar."MACRO-a"/1>
   

   To get things to compile, a needs to be rewritten to return valid AST:

     defmacro a do
       quote do
         Foobar.other(&Foobar.b/1)
       end
     end
   

I suspect, however, that this might not address the actual code that this example was based off of. What I think you’re trying to do is to defer macro expansion until runtime. This isn’t possible except by evaluating a quoted expression, but that is a whole other can of worms. If this is the case, it’s worth reconsidering the approach.