I’m not fully understanding how matching works with function arguments. In Functions and Pattern Matching it is explained (IMO poorly) that everything in the argument is matched independently. As a result this experiment I made works:
iex(6)> test = fn (%{a: x} = %{b: y}) -> IO.puts "x:" <> x <> " y:" <> y end
#Function<42.18682967/1 in :erl_eval.expr/6>
iex(7)> test.(%{a: "what", b: "happened"})
x:what y:happened
:ok
iex(8)>
But I don’t fully understand the semantics of this. Is the = here the same match operator as usual? I tested the match operator alone for this behavior and it does seem to match everything!
So it seems that the match operator is both associative and commutative which I did not expect. I also assume passing arguments is the same as including another match with the passed argument. (this is correct)
Where is this documented? A quick search on the Elixir hexdocs of = and match aren’t fruitful. Pattern matching — Elixir v1.19.0-dev doesn’t say anything about it.
Edit: I think the article may just be wrong or poorly worded. I still need some clarification though
Thank you @LostKobrakai for clarifying things. The match operator always returns the right side value or fails with an error.
Are you saying that x is assigned with "what" because the first match %{b: y} = %{a: "what", b: "happened"} includes a?
I’m testing out forcing the left side to evaluate first and it still seems to match. I also included a match with undefined variables first to see what the error is, and then after to see if the two independent maps match because they don’t have conflicting values.
iex(1)> %{a: x} = %{b: y}
error: undefined variable "y"
└─ iex:1
** (CompileError) cannot compile code (errors have been logged)
iex(1)> (%{a: x} = %{b: y}) = %{a: "what", b: "happened"}
%{a: "what", b: "happened"}
iex(2)> x
"what"
iex(3)> y
"happened"
iex(4)> %{a: x} = %{b: y}
** (MatchError) no match of right hand side value: %{b: "happened"}
(stdlib 6.2) erl_eval.erl:667: :erl_eval.expr/6
iex:4: (file)
iex(4)>
But it would match if there were partial keys matching?
I think I’m starting to get the semantics here: match(pattern, pattern) -> option<pattern> (pseudo-code types) and finally it builds until there are no match operators and you have one pattern that defines the undefined variables in it.
Apologies that my vocabulary is a bit imprecise here.
No I’m wrong. It is not commutative or associative. It’s RTL 100% like @derek-zhou says, but you have more freedom to re-arrange the order on the left hand side because of either some match semantics or map semantics I don’t fully understand.
Again I’m confused about what the section here: Functions and Pattern Matching is saying about pattern match independence:
If we switch the order of %{name: person_name} and person in the list, we will get the same result because each are matching to fred on their own.
We swap the variable and the map:
defmodule Greeter3 do
def hello(person = %{name: person_name}) do
IO.puts "Hello, " <> person_name
IO.inspect person
end
end
And call it with the same data we used in Greeter2.hello/1:
Remember that even though it looks like %{name: person_name} = person is pattern-matching the %{name: person_name} against the person variable, they’re actually each pattern-matching to the passed-in argument.
Is the article just wrong or poorly worded? person = %{name: person_name} seems to match person with the full map because %{name: person_name} = fred results in a match on the full map.
I stepped away to eat, and looking at this again with a clear head is mostly embarrassing. Nonetheless, there are some subtleties concerning variable assignment to clarify.
The match operator only assigns variables on the left side, but you can still match with undefined variables on the right if the match is part of a larger expression where they will be bound. This is why giving the left match precedence in (%{a: x} = %{b: y}) = %{a: "what", b: "happened"} works.
What initially threw me off from this article Functions and Pattern Matching still confuses me though. It states: “Remember that even though it looks like %{name: person_name} = person is pattern-matching the %{name: person_name} against the person variable, they’re actually each pattern-matching to the passed-in argument,”. Is this incorrect? Are there special pattern match rules within function signatures? Isn’t it just the same as matching RTL starting with the argument on the right most side?
I think the article has pretty clear wording, for example if you have:
def hello(%{name: person_name} = person) do
IO.puts "Hello, " <> person_name
IO.inspect person
end
The value person will have the entire map passed as the argument binded to it and person_name will bind the value of the key name. This kind of match also enforces the argument to be a map and contain the name key.
Yes, the ultimate bindings are clear My problem is understanding the nuances.
The article says that reversing the match order:
defmodule Greeter3 do
def hello(person = %{name: person_name}) do
IO.puts "Hello, " <> person_name
IO.inspect person
end
end
results in a successful match with fred “because each are matching to fred on their own” and later says “Remember that even though it looks like %{name: person_name} = person is pattern-matching the %{name: person_name} against the person variable, they’re actually each pattern-matching to the passed-in argument”.
I read this to mean an expression like this: (person = fred) = (%{name: person_name} = fred) is happening opposed to: person = (%{name: person_name} = fred) although I think the latter is in fact correct.
I’m thinking the reason you can switch the order here is not because they are “matching to fred on their own” but because the %{name: person_name} = fred match, results in the whole map which can be bound to person to the left. Just like what happens with %{a: x} = %{b: y} = %{a: "what", b: "happened"}.
This is what I’m seeking clarity on and find poorly worded.
I’d start from some underlying primitives here and build up understanding from there:
In elixir everything is an expression, which can be evaluated to a value – there are no statements or void return values.
E.g. x = if 1 < 2, do: :a, else: :b will bind x with :a
The value returned by a match expression is the value of the right hand side value in the match expression.
So for ^y = (pattern = y) the pattern = y will evaluate to the value of y
In the above the binding of pattern is kind of a side effect as it doesn’t affect the return value of the match expression.
Therefore for the outer match expression ^y = (pattern = y) can be simplified to ^y = y
Being right associative match expressions can be chained without affecting the above properties even if you leave out explicit parenthesis. Each chained match expression will evaluate to the right most “input”, with all the individual match expressions having the chance to fail matching as well as resulting in variables being bound as side effects of their matching. a = %{b: 1} = %{d: d} = %{b: 1, d: 4} and the following function essentially the same.
These properties make it essentially irrelevant in which order patterns are placed in a chained set of match expressions, though only the patterns, the right most value needs to stay on the right. Yes technically there is an order – you could move least permissive match patterns more right to match earlier than less permissive ones – but in practise that’s really irrelevant.
Now finally moving to function parameters. Usually these cause confusion because the actually imporant “right most input” doesn’t actually show up when writing a function head.
Having a function shows just a chained set of match patterns.
def my_function(a = %{b: 1} = %{d: d}), do: […]
When calling my_function(%{b: 1, d: 4}) internally you’ll essentially get these patterns evaluated as: a = %{b: 1} = %{d: d} = %{b: 1, d: 4}, adding the provided parameters to the right most side of the chain.
Hence in function heads you can reorder all parts of a chained match expression given the input isn’t present explicitly and it wouldn’t functionally change the function (beyond microoptimizations).
Thank you, this clarifies almost everything and explains why the article says that every pattern is matched independently with the argument. I appreciate the time you put into explaining this!
There remains a gap in my understanding. Giving precedence to %{a: x} = %{b: y} in (%{a: x} = %{b: y}) = %{a: "what", b: "happened"} is a successful match binding x to "what" and y to "happened". So the execution order does not appear to naively follow the order of the expression.
I don’t think you can “give” precedence to the pattern match with ( ). I think they will just be ignored
In your example (%{a: x} = %{b: y}) = %{a: "what", b: "happened"} is a pattern match where the rightmost value is %{a: "what", b: "happened"}, so it has to be known and can’t bind variables, and the left side is (%{a: x} = %{b: y}) which is a pattern that the mentioned value has to satisfy. It means that the value need to satisfy both %{a: x} and %{b: y} and it will check against %{b: y} first before doing %{a: x}. That means that if the match fails on both patterns, the execution will stop and error on the b match first, but in order for match to succeed, all the patterns on the left side need to be matched.
So you are not comparing %{a: x} to %{b: y} - these are patterns for the same input. The only way when two patterns on the left side can interrupt each other is when they bind to the same variable, as there is a rule that value can be bind multiple times in one expression only if it binds to the same value. So %{a: x} = %{b: x} = %{a: "what", b: "happened"} will fail
EDIT:
Ok. No longer so sure enough about this statement to give tips on how it actually works. I simply always perceived match operator as folding from right to left, checking patterns in the process but it might be just my mental model
and it will check against %{b: y} first before doing %{a: x}. That means that if the match fails on both patterns, the execution will stop and error on the b match first, but in order for match to succeed, all the patterns on the left side need to be matched.
My intuition matches yours. Conceptually (%{a: x} = %{b: y}) is itself a pattern which intersects %{a: x} and %{a: y}. This pattern is then matched with the value on the right, and it’s probably implemented by transforming the order of execution as if it wasn’t there.
It’s just that this behavior is not specified or documented anywhere I can see. There are no other operators producing patterns for the left side like this right? This is a very special case?
Erlang pattern matching is inspired by prolog. In prolog you can have bindings on both sides of match and it will try to solve it like an equation. I think erlang also supports a limited version of this behavior.
default_precedence() ->
#{a := <<"foo">>, b := <<"bar">>} = #{c := <<"qux">>} =
#{a => <<"foo">>, b => <<"bar">>,
c => <<"qux">>}.
left_precedence() ->
(#{a := <<"foo">>, b := <<"bar">>} = #{c :=
<<"qux">>}) =
#{a => <<"foo">>, b => <<"bar">>, c => <<"qux">>}.
By the time the expressions get to the BEAM they still have the parenthesis on the left hand side. So my question is as much an Erlang one as it is an Elixir one.
Erlang syntax does look Prolog-esque! especially with the dashes for declarations. I’ll be dogged if pattern matching is anything like horn clauses though. That said, Erlang pattern matching seems to have a little more than meets the eye given what we’re looking at here.
A few years ago we in the compiler team at OTP started to get bug many bug reports about the Erlang compiler crashing when compiling some “strange” Erlang code. It turned out that the Erlang code that triggered the crashes was generated by a fuzzer, erlfuzz.
One of the classes of bugs in the Erlang compiler and in the documentation was in pattern matching. We had many discussions in the OTP team about how to best describe pattern matching and how to fix the compiler to be consistent and never crash.
The result was that we realized that there is not one match operator, but two distinct operators: the match operator and the compound match operator.
Here is the revised documentation about matching resulting from those bug reports and our discussions:
I’m reading it now. I think this concurs with my reading of the Elixir School article and the match is distributed over the left compound pattern: The Match Operator and the Compound Pattern Operator “Since the construct inside the parentheses is a pattern, the = that separates the two patterns is the compound pattern operator (not the match operator). The match fails because the two sub patterns are matched at the same time”
Assuming the function argument pattern is compound, it actually is more like the former and the article has been right this whole time!
Let me double check with the example in Elixir:
iex(38)> m = %{key: :key2, key2: :value}
%{key: :key2, key2: :value}
iex(39)> %{k => :value} = %{key: k} = m
error: cannot use variable k as map key inside a pattern. Map keys in patterns can only be literals (such as atoms, strings, tuples, and the like) or an existing variable matched with the pin operator (such as ^some_var)
└─ iex:39
** (CompileError) cannot compile code (errors have been logged)
iex(39)> %{^k => :value} = %{key: k} = m
error: undefined variable ^k. No variable "k" has been defined before the current pattern
└─ iex:39
** (CompileError) cannot compile code (errors have been logged)
iex(39)> (%{^k => :value} = %{key: k}) = m
error: undefined variable ^k. No variable "k" has been defined before the current pattern
└─ iex:39
** (CompileError) cannot compile code (errors have been logged)
It seems Elixir prevents the edge case where the order of operation makes a difference by preventing the variable being used as a map key within the pattern. But I take it from here that the matches really are independent under the hood, and that this nuance almost never matters.
Thank you so much, this was really bugging me
Well onto lesson 7
(this is correct)
My problem is understanding the nuances.
