stephen_m
Multiple clauses, defaults and conflicts
Hi,
When writing the following code, elixir correctly and thankfully warns that there is a conflict:
function/macro 1:
defmacro static_translate(key, opts \\ [humanize: :true, downcase: :true]) do
... do stuff here
end
function/macro 2:
defmacro static_translate(module, key, opts \\ [humanize: :true, downcase: :true]) do
...do other stuff here
end
error
web/views/views_translation_helpers.ex:59: defmacro static_translate/3 defaults conflicts with defmacro static_translate/2
I’ve been dealing with these situations a few times and I’m never quite happy with my refactoring…
how would you rewrite this?
(please assume the function logic is sufficiently different to warrant a separate function completely)
Marked As Solved
NobbZ
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.
Also Liked
peerreynders
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)>
peerreynders
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
davearonson
Looks to me like you’re saying module is optional… so maybe you could make module one of the opts?
JHG
Thanks!
same({1,2},3)could be interpreted verbatim as calling
same/2or assame({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.







