Multiple clauses, defaults and conflicts

The only possible way to refactor here is to rename one of the macros/functions.

def foo(bar, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...

is getting expanded at compile time to the following:

def foo(bar), do: foo(bar, [])
def foo(bar, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...

As you can see, there are now 2 foo/2, which is the mentioned conflict in the error you posted.

Thanks for the answer… This is what I did in the end.

My refactoring ended up like this…

defmacro static_translate(key, opts \\ [humanize: :true, downcase: :true]) do
end

defmacro dynamic_translate(key, opts \\ [humanize: :true, downcase: :true]) do
   module = MyApp.module
   ......
end

I wasn’t sure if renaming was bad or not. In this case, it turned out better because the second one is a dynamic translation – but regardless of that if it wasn’t, I would not have wanted to rename.. but if this is the only way, then so be it.

Cheers for your input.

This is why I link to call everything via Modules. I have alias MyServer.Perms for everything related to Perm is called like Perms.Admin.blah and so forth. If it is a long module name I :as it to something shorter, but I always like to have names being called. It prevents these issues and lets me know ‘where’ something is that I am calling.

EDIT: Or wait, I think your above functions are in the same module? Yeah that is a big conflict then.

Either make different names for them (as you did) or make a ‘header’ function that calls whichever specific it needs.

Looks to me like you’re saying module is optional… so maybe you could make module one of the opts?

in this case module is not optional but fair suggestion…

Good explanation. I get similar error but in a case a bit different. For example:

iex(1)> defmodule Test do
...(1)> def same({a, b}, c), do: 1
...(1)> def same({a, b}), do: 2
...(1)> def same(a, b, c \\ 1), do: 3
...(1)> end
iex(2)> Test.same({:ok, :ok})
2
iex(3)> Test.same({:ok, :ok}, :ok)
1
iex(4)> Test.same(:ok, :ok, :ok)  
3
iex(5)> Test.same(:ok, :ok)     
3

With that code everything well. But if I try to do that c to be optional for the case where I match with a tuple of 2 elements then I get the error about defaults conflicts.

iex(8)> defmodule TestAgain do       
...(8)> def same({a, b}, c \\ 1), do: 1
...(8)> def same(a, b, c \\ 1), do: 3  
...(8)> end

** (CompileError) iex:10: def same/3 defaults conflicts with same/2
    iex:10: (module)

But the code that, if I understood well, is equivalent to same({a, b}, c \\ 1) works well. Could this case be an error in compiler that check the number of arguments but does not check the pattern matching in arguments?

(I replied in this thread as it’s about same topic, I’m not sure if it’s better open new thread or to reply here).

Welcome to the forum!

same({1,2},3)

could be interpreted verbatim as calling same/2 or as

same({1,2}, 3, 1)

due to the optional parameter on same/3.

How is the compiler supposed to know which one you mean?

Don’t mistake pattern matching for static typing.

Note:

iex(1)> defmodule Test do
...(1)>   # same/3
...(1)>   def same(_a, _b, _c \\ 1), do: 3
...(1)>   # same/2
...(1)>   def same({_a, _b}, _c), do: 2
...(1)>   # same/1
...(1)>   def same({_a, _b}), do: 1
...(1)> end
** (CompileError) iex:5: def same/2 conflicts with defaults from same/3 
    iex:5: (module)
iex(1)> 

i.e. you should have gotten an error on your first example.

Your ordering happened to create this:

iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_a, _b}), do: 1
...(1)>   # same/2
...(1)>   def same({_a, _b}, _c), do: 2
...(1)>   def same(a, b), do: same(a, b, 1) 
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
{:module, Test,
 <<70, 79, 82, 49, 0, 0, 4, 240, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123,
   0, 0, 0, 13, 11, 69, 108, 105, 120, 105, 114, 46, 84, 101, 115, 116, 8, 95,
   95, 105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:same, 3}}
iex(2)> Test.same({:ok, :ok})
1
iex(3)> Test.same({:ok, :ok}, :ok)
2
iex(4)> Test.same(:ok, :ok, :ok)  
3
iex(5)> Test.same(:ok, :ok) 
3
iex(6)>

The behaviour you are looking for seems to be this:

iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
{:module, Test,
 <<70, 79, 82, 49, 0, 0, 5, 8, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123, 0,
   0, 0, 13, 11, 69, 108, 105, 120, 105, 114, 46, 84, 101, 115, 116, 8, 95, 95,
   105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:same, 3}}
iex(2)> 
nil
iex(3)> Test.same({:ok,:ok})
2
iex(4)> Test.same({:ok,:ok}, :ok)
2
iex(5)> Test.same(:ok, :ok)
3
iex(6)> Test.same(:ok, :ok, :ok)
3
iex(7)> 

Thanks!

same({1,2},3)

could be interpreted verbatim as calling same/2 or as

same({1,2}, 3, 1)

due to the optional parameter on same/3 .

How is the compiler supposed to know which one you mean?

Then I din’t understand the explanaiton of @NobbZ because what I understood is not that same({a, b}, c) could be interpreted as a call to same/2 or same/3 and then it check what call to do. I though what it is expanded to 2 definitions, then the previous call always will be same/2 and then as the pattern matching in the argument is before of same arity without that it’ll match with the first (as it’s expected).

@NobbZ said:

def foo(bar, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...

is getting expanded at compile time to the following:

def foo(bar), do: foo(bar, [])
def foo(bar, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...

Then, in that example 2 functions have same arity and don’t do pattern matching in one, then I won’t can call to both; but with the pattern matching in one argument, if this is before of argument without it, I’ll can call to both. Of course, there is not so much sense to order with same arity without the tuple matching in one argument first because then nothing will match because it’s checked in order. But, if:

def foo({bar, bax}, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...

is getting expanded at compile time to the following:

def foo({bar, bax}), do: foo({bar, bax}, [])
def foo({bar, bax}, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...

As, if it’s correct, the expansion is in the function code, not in the call, a call as foo({1, 2}, 3) is always foo/2 then it must match with:

def foo({bar, bax}, baz), do: ...
def foo(quux, bar), do: foo(quux, bar, %{})

And because the order is correct, with the argument that match the tuple before, then it’ll match with first of foo/2. Then my second example in first post:

...(8)> def same({a, b}, c \\ 1), do: 1
...(8)> def same(a, b, c \\ 1), do: 3  

if expands to:

def same({a, b}), do: foo({a, b}, 1)
def same({a, b}, c), do: ...

def same(a, b), do: foo(a, b, 1)
def same(a, b, c), do: ...

Must works (and it works if I write as it’s expanded), then if compiler can’t expand a code that’s correct when it’s write as expanded, isn’t it an error? I understand that if it only check arity then try to avoid error, but when it as matchings in arguments it could be correct and works. Only problem could be if it doesn’t expand the function definition and it expand functions calls, that I didn’t understood that way.

The behaviour you are looking for seems to be this:

iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end

Yes, I used 1, 2 &3 only to show in console where it did the call, but that’s the correct behaviour. What I tried to tell is what that could be written as:

iex(1)> defmodule Test do
...(1)>   def same({_a,_b}, _c \\ 1), do: 2
...(1)>   def same(_a, _b, _c \\ 1), do: 3
...(1)> end

And expanded to:

iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end

But:

iex(22)> defmodule Test do                          
...(22)> def same({_a,_b}, _c \\ 1), do: 2          
...(22)> def same(_a, _b, _c \\ 1), do: 3          
...(22)> end
** (CompileError) iex:24: def same/3 defaults conflicts with same/2
    iex:24: (module)

When the expected expand will work well and won’t raise errors compiling the expanded version.

Then, maybe compiler could not to raise the error when even arity is same the arguments have something that can match, specially when the order is correct (if order is not good compiler show a warning), not to force to write the expanded version when the idea of \\, I think, is not to write the expanded version, to do same with less, compiler is not avoiding error, is raising an error in a code that expanded will work well.

EDIT: Or I’m ignoring something I don’t know/understood about expansion and the compiler and it makes sense not to do that expansion and avoid it to avoid errors.

That is actually

# same/1
def same({a, b}), do: same({a, b}, 1)

# same/2
def same({a, b}, c), do: ...
def same(a, b), do: same(a, b, 1)

# same/3
def same(a, b, c), do: ...

which is equivalent to

# same/1
def same({a, b}), do: same({a, b}, 1)

# same/2
def same(arg, c) do
  case arg do
    {a,b} -> ...
    _ -> same(arg, c, 1)
  end
end

# same/3
def same(a, b, c), do: ...

Optional parameters are not a feature of the underlying language - Erlang. It’s something that Elixir layers on top in a way that “works most of the time as expected”. But there can be surprising edge cases.

This creates ONE function (same/2):

def same({a, b}, c), do: ...
def same(a, b), do: ...

This creates TWO functions (same/2 and same/3):

def same(a, b, c \\ 1), do: ...

Taking that into account

# this emits code for same/1 and same/2
def same({a, b}, c \\ 1), do: 2

# this emits code for same/2 and same/3
def same(a, b, c \\ 1), do: 3

The error probably relates to the fact that two separate clauses with optional function parameters emit code for the same function: same/2.

The intent that is behind

def same({_a,_b}, _c \\ 1), do: 2          
def same(_a, _b, _c \\ 1), do: 3 

cannot be implemented with optional parameters but can be implemented long-hand

def same({_,_} = arg), do: same(arg, 1)

def same({_a,_b}, _c), do: 2
def same(a,b), do: same(a,b, 1)

def same(_a, _b, _c), do: 3

Thanks @peerreynders I think I get it now with:

Optional parameters are not a feature of the underlying language - Erlang. It’s something that Elixir layers on top in a way that “works most of the time as expected”. But there can be surprising edge cases.

This creates ONE function ( same/2 ):

def same({a, b}, c), do: ...
def same(a, b), do: ...

I expected Elixir could handle it. I guess I found one of that surprising edge cases.

I don’t know if to enhance optional parameters is in the roadmap (in the end, it’s not important as it can be handle long-hand) but it’s nice, hopeful it’ll have less edge cases over time.

Thank you so much for the explanation!