Strategy to avoid particular transitive compile-time dependency

Questions / Help
1

As part of Understanding a spike in app compilation time, I’m trying to remove compile-time dependency that’s based on defguard macro.

With the code below, Elixir reports a transitive compile-time dependency:

mix xref graph --label compile-connected
lib/example1.ex
└── lib/guards.ex (compile)

How would one go about change the code to avoid the transitive dependency, while (ideally) preserving the defguard macros?

For context, this is a simplified example of production code. The reason lib/guards.ex is a separate file is code re-use - it’s typically included into other modules to offer the guards.

The code looks like this (repo is available here, for reference):

# lib/example1.ex
defmodule Example1 do
  import Example1.Guards

  def user(user) when is_admin(user), do: IO.puts("This user is an admin: #{inspect(user)}")

  def user(user) when is_customer(user), do: IO.puts("This user is a customer: #{inspect(user)}")
end

# lib/guards.ex
defmodule Example1.Guards do
  defguard is_admin(user) when is_struct(user, Example1.Admin) == "admin"

  defguard is_customer(user) when is_struct(user, Example1.Customer) == "customer"
end

# lib/admin.ex
defmodule Example1.Admin do
  defstruct role: :admin
end

# lib/customer.ex
defmodule Example1.Customer do
  defstruct role: :customer
end

Since both defguard and is_struct(anyVariable, AnyModule) are not supposed to make any function calls on the AnyModule - maybe there’s no reason to report a compile-time dependency in such case, is there?

2

Custom guards are not much different than macros (in the past one would’ve used macros). So when compiling lib/example1.ex those used guards are replaced with the code from lib/guards.ex, because erlang/the beam don’t allow for user defined guards – hence replacement at compile time.

So whenever lib/guards.ex changes lib/example1.ex needs to be recompiled as well or you’d get stale code. That’s a classic compile time dependency – not a transitive one as well.

3

Are you saying that the transitive dependency appears specifically due to use of custom guards? If yes, then that’s not what I am seeing :thinking:

For example, if I change the code in guards.ex to the following, then re-run the mix xref check, nothing is being reported:

defmodule Example1.Guards do
  defguard is_admin(user) when user == "admin"

  defguard is_customer(user) when user == "customer"
end

mix xref graph --label compile-connected
# empty output

Or is it the is_struct that you’re referring to as a custom guard?

4 
$ mix xref graph 
lib/admin.ex
lib/customer.ex
lib/example1.ex
└── lib/guards.ex (compile)
lib/guards.ex
├── lib/admin.ex
└── lib/customer.ex

So the lib/example1.ex -> lib/guards.ex is a compile dependency and that doesn’t go away when changing the guards. The change only means there no longer is a transitive compile time dependency caused by it.

lib/guards.ex
├── lib/admin.ex
└── lib/customer.ex

That part is the dependency, which due to the prev. compile time dependency becomes a transitive compile time dependency. That should be due to to the fact that the module names Example1.Admin and Example1.Customer are part of the code for the guard (same issue with macros). I’m not sure there’s any way around that, which would work in defguard.

5 
  @admin Module.concat(["Example1", "Admin"])
  @customer Module.concat(["Example1", "Customer"])
  defguard is_admin(user) when is_struct(user, @admin)
  defguard is_customer(user) when is_struct(user, @customer)

This seems to work. Module.concat is also what you’d commonly see in macros for those issues.

2 Likes
6

What is your Elixir version? Those defguards should not be adding compile-time dependencies.

7

1.14.0 on my end

8

Ignore me. I was too quick to read. They are not compile-time dependencies, they are runtime dependencies but which makes guards transitive.

Your trick would solve it but ultimately I hope people won’t rely on it. :smiley: I need to think a bit more about this problem.

9

What is the problem with relying on that, other than that it’s ugly?

I learned those tricks like when I was having similar issues but I ultimately decided against just because they felt wrong, but of course couldn’t explain why in terms of if if it would cause any issues. Would they?

I’ve ultimately ended up going with def user(%Admin{} = user), do: # ... / def user(%Customer{} = user), do: # ... which I actually sort of like better as it’s super explicit as to the type. Custom guards can still be used for checking roles, but part of me wonders if I would switch back to what @gmile is doing if it didn’t cause issue.

10

The only reason you are doing it is to work around a compiler behaviour and that to me is a smell. :slight_smile:

1 Like
11

That’s what my only argument, but that wasn’t enough ammo to stop my old coworker from doing it :upside_down_face:

12

You can print the previous comment in case it has any persuasive power :slight_smile:

BUT GOOD NEWS

It will no longer be required from Elixir v1.15. I realized that patterns and guards cannot add runtime dependencies to modules because they can never call said modules, so the compile-connected dependency should fully disappear in v1.15.

Thanks everyone for the helpful discussion!

12 Likes