Documentation of what an "MFA" is?

In context of typespecs:

mfa()	{module(), atom(), arity()}

For child_spec() Erlang uses mfargs() to refer to a {M,F,A} tuple (module, function atom, arguments list - Kernel.apply/3, :erlang.apply/3).

Its a good question! The nearest I could find was an erlang type definition in the docs at Types and Function Specifications — Erlang System Documentation v29.0.2

This has recently come up for me as I am working on a library where I am adding support for a “function reference” argument. Previously I was expecting {module, function, args} even though the args component was not really used for anything simply because that format seems to be universal in Elixir. But due to a behavior change I really need to know what arity to expect and I’m sort of at a loss when it comes to best practice!

I am using NimbleOptions and there is no built in support for this. In fact, the documentation has this line which was puzzling to me right off the bat:

:mfa - A named function in the format {module, function, arity} where arity is a list of arguments. For example, {MyModule, :my_fun, [arg1, arg2]}.

(There is also {:fun, arity} but in my use case the module is also variable, edit: and also on closer reading this appears to be for functions of set arity?)

I have to wonder why it seems that in Elixir mfa has come to mean specifically the args variation and I don’t think I’ve seen a mfargs type in the wild…

Do you mean for enforcing that it has a specific arity or supporting functions that have unknown arities? Not sure about best practices as I prefer to support them all as a matter of flexibility.

For unknown, the {SomeModule, :function, args} is what I would reach for. I rarely use it in practice though:

def call_mfa(a, b, {module, function, args}),
  do: apply(module, function, [a, b | args])

Then all the others -

• {SomeModule, :function}
• &SomeModule.function/2
• fn _a, _b -> :ok end

For expected arity, it’s just the others (i.e. no {m, f, a}).

Not sure about that option for NimbleOptions, but I think it can take a capture like &Enum.map/2, which would cover the bases of requiring a specific arity. Then it’s just a matter of taste on whether you want to support {SomeModule, :function}.

Edit:

Yeah I was actually surprised to see it called arity because that would imply it should be {MyModule, :my_fun, 2}, right? It would be interesting to know the historical context of calling the third element arity.

Both, I think. Possibly I am missing some angle but in my use case I intended to require the user specify a function, which requires specifying an arity, without making any assumptions about the arguments.

I suppose I could allow them to specify only the function name, but in that case I would have to simply pick the first function defined in the module with that name, which seems like undesirable ambiguity. I could see why in many cases it wouldn’t matter, since the user controls the function and the option, so it can be left to them to pass the correct configuration that matches their implementation, but in my case I can’t infer the desired arity from the option (for reasons I don’t think are relevant here).

Mostly however I am just confused about the mfa/mfargs mismatch between Elixir and Erlang.

Did a little code excavation and it turns out that, even in the Erlang repository “mfa” can mean both, but if in the “args” variant, I see a lot more adhoc type specs. It’s probably one of those cases where its interchangeable use has caused it to have multiple meanings. It does help that you can match on the third element for the various cases:

• {m, f, a} when is_integer(a) and a >= 0 - known arity
• {m, f, :_} - unknown arity
• {m, f, a} when is_list(a) - args instead of arity

I think capturing &SomeModule.function/2 is more familiar, but {SomeModule, :function, 2} does make it easier to check if the function exists (vs having to check the capture with Function.info/2).

afair I read mfa in typespec section in Elixir hexdocs.