Function refs in guards

I was creating simple RPN calculator function, but I stumbled upon a problem in matching functions in guards.

Code looks like so:

def compute_RPN_expr(value, stack) when is_number(value), do: [value | stack]

def compute_RPN_expr(operator, stack) when operator in [&+/2, &-/2, &*/2, &//2] do
  [a, b | stack] = stack
  stack = [operator.(b, a) | stack]

After trying to define it inside IEX I’m getting invalid expression in guard, & is not allowed in guards.

Why? I can do:

a = &//2
a === &//2

Without much hassle, but I can’t use the same equality test via in.
Is there any Elixir/Erlang limitation or this was simply overlooked?

1 Like

In general you can’t compare functions for equality. So even if it were syntactically allowed, it wouldn’t make sense semantically.

Instead you should use atoms as operators and map them to functions.

Why so? This would work like a comparing function pointers in C - checking their address. I’m kinda expecting doing most operations on normal variables will work on functions too. So, for me it makes sense if I’m passing function f as argument and inside some function I’m checking if I actually passed exactly f. I know this thing isn’t broadly used, but in some applications can be useful. Mapping atoms to functions creates another level of indirection, but I’ll give it a go.

There are no function pointers in elixir.

&+/2 is different in every module you write this. Also, even though both of the following functions are obviously producing the same result for their respective domains, you can’t computationally compare them for equality without doing manual prooves:

def multiply_a(a, b), do: a * b

def multiply_b(0, _), do: 0
def multiply_b(_, 0), do: 0
def multiply_b(1, b), do: b
def multiply_b(a, b) when a > 0, do: b + multiply(a - 1, b)
def multiply_b(a, b) when a < 0, do: multiply(-a, -b)

Both of these functions are “equal” to */2, but for the latter it will be very hard to proof in a language like elixir.

Just rewrite your dispatcher to use atoms (or accept all functions with arity 2).

def f(op, [a, b | s]) when op in [:+, :-, :*, :/], do: [apply(:erlang, op, [a, b]) | s]
def f(v, s) when is_number(v), do: [v | s]

def g(op, [a, b | s]) when is_function(op, 2), do: [op.(a, b) | s]
def g(v, s), do: [v | s]

One important reason is hot code reloading and the distributed kind of Erlang/Elixir programs: If you are running code on multiple nodes, then they both have separate versions of the functions that might be executed (and if you try to upgrade both nodes to a new version, they are not guaranteed to upgrade at exactly the same time). If you pass on a function reference from one node to the next, it has to be transformed to an intermediate representation on one side, and back on the other side.

In short: The reference on one node will not point to the same location as the one on the other node. This means that we cannot check for equality (which is stronger than, but would infer, equivalence, which is what your code actually requires) by comparing pointers.

In Erlang/Elixir, all data structures can be checked for structural equivalence by matching on them. However, functions are, for the reason outlined above, opaque, so we cannot check their internals.

And therefore, an extra symbolic intermediate step like what @NobbZ proposes is required.

In a more general sense, you can never prove the equivalence of two functions, because this would be the same as solving the Halting Problem. The only thing you could do is to prove that two functions are equivalent because they are equal (exactly the same instance), but this is something that is not possible in Elixir because of above-outlined restrictions imposed by the distributed nature of Elixir’s runtime system.


I don’t want to prove that function A is equals to function B. I Just want to compare them by address, e.g.

iex(1)> a = &Float.round(&1, &2)
iex(2)> b = &Float.round(&2, &1)
#Function<12.127694169/2 in :erl_eval.expr/5>

Those 2 functions above aren’t the same, even when they’re doing the same thing. So a != b.
is_function/2 may be good idea, I’ll try it, thanks.

@Qqwy, thanks for explanation; I’ve got one question: is any tutorial somewhere which covers Elixirs internals or I have to learn Erlang/BEAM low level stuff and then translate to Elixir from source code?

@Jump3r There are not many cases in which you actually touch the Erlang/BEAM low-level stuff directly or have to keep them in mind (most of the time, Elixir’s abstractions are very leak-free). However, I would recommend watching Solid Ground because it will give you a good high-level foundation of understanding what trade-offs have been made in Erlang/BEAM :slight_smile:.

3 Likes is a good resource for looking at the internals of how the BEAM itself works. Decisions and capabilities like the one you’re describing are gonna either be present or absent on the basis of the BEAM itself, Elixir just gets compiled to BEAM byte code.


Why is :erlang the module in MFA.

You could use Kernel, but those just forward to the erlang implementations anyways: