Import and macro conflict

Questions / Help
,
1

Hello.

Suppose we have a file with this code

import ImportMe

defmodule AModule do
  use UseMe
end

where the modules above are defined in another file like this

defmodule ImportMe do
  def bar, do: :ok
end

defmodule UseMe do
  defmacro __using__(_opts) do
    quote do
      def foo, do: bar()
      def bar(), do: :ok
    end
  end
end

The compilation of these two files produces the imported ImportMe.bar/0 conflicts with local function error in the first file.

Is this something that should be reported as a bug or not?

Thanks

2

Why would it be a bug? You clearly have two functions named bar available in the same scope. What if you change the order of your functions to:

def bar(), do: :ok
def foo, do: bar()

What should is call in that case? It’s not clear.

2 Likes
3

Switching the order of the definitions inside UseMe generates the same compilation error.

Why would it be a bug?

The modules ImportMe and UseMe are not freely composable (i.e., some uses result in a compilation error).

If the modules are the responsibility of the same team, then things are easy to solve (just rename the functions).

But if the modules come from disparate teams, then the developer must use ImportMe.bar/0 qualified.

A similar situation results when trying to use A and use B, and A and B define the same named function with the same arity.

This might be an unintended limitation with macros, or something that one must live with, hence my question.

4

I’m not really sure how this is related to macros at all. You have two different functions named the same in the same scope. That’s not going to work well. The compiler cannot decide for you which of the two ones it’s supposed to call. How those named functions ended up in the same scope shouldn’t make any difference.

1 Like
5

This is related to macros because it relates to injecting definitions in a scope where the same definition already exists.

This is breaking macro hygiene: more specifically, if injecting a variable is not a problem, then injecting a definition should not be a problem too. (See macro hygiene).

6

:only and :except options are available for import, you can use them to steer the compiler in the right direction.

But if you want hygiene for macro defined functions as you have them for variables, fine. You made macros useless, as from now on funtions defined in a macro don’t leak the macro anymore!

7

But if you want hygiene for macro defined functions as you have them for variables, fine. You made macros useless, as from now on funtions defined in a macro don’t leak the macro anymore!

I was almost going to agree with this, but then I remembered that the injected functions are accessible through the AModule interface. So macros do not become useless.

8

When you are in AModule, there is no difference between bar and AModule.bar.

Just cope with it. Calling a macro is the same as copy and pasting code into your file. If you do not want a function f generated, then do not call the macro.

If you do not want to import a function g, then :exclude it from the import list.

That aside, I have a very strict opinion about libraries narrowing my own available namespace by dumping arbitrary functions into my module. But I think we already argued about this a lot in the slack…

1 Like
9

To add to that: The best way to have independency is to not use a single module. That way macros cannot conflict with each other.

10

I never observed this before, it just happened now by chance, so that discussion in Slack was not with me.

Yep, avoiding import is the way to go in this situation, as mentioned above, and solves your concerns regarding limiting your namespace.