[erlang-questions] Proposal for not allowing tuple calls

[José Valim]

More than a year ago, the OTP team has decided to not remove tuple calls
from the language i.e. this is valid Erlang code:

({erlang, 1, 2, 3}):is_tuple().

Most times though, such calls are written in the format:

Var:some_fun(Arg1, Arg2).


The reasoning is that we had to maintain backwards compatibility since such
calls were used by many projects. This behaviour has many downsides though,
many of them debated in this mailing list, for example the performance hit
of such calls as well as the fact this behaviour is confusing, specially
when you accidentally trigger it for the first time.

Furthermore, erlang:apply/3 also allows tuple calls, not giving us any
alternative to disallow such behaviour, even if it explicitly.

For those reasons, I would like to propose a new function and a compiler
option that disables the tuple calls.

erlang:apply_no_tuple(Mod, Fun, Args).

The function above works as apply, except it will raise badarg unless Mod
is an atom. The idea is that the optimizations we had in mind for the
regular dispatch could now be applied to this new function.

We could also have a compiler option, no_tuple_calls, that will compile all
underlying Var:some_fun(Arg1, Arg2) into erlang:apply_no_tuple/3 instead of
erlang:apply/3 for the current module. This is a great opportunity because
build tools like rebar3, mix and erlang.mk could ship with such option as a
default, slowly phasing out the tuple behaviour. In the long term, we could
even make the tuple call behaviour opt-in (rather than opt-out).

PS: erlang:apply_no_tuple/3 and no_tuple_calls are horrible names but I
believe we can find good names along the way if there is interest. Another
alternative I had in mind was erlang:apply_strict/3 and only_strict_calls
for the compiler option.

*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Lead Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150411/412114aa/attachment.htm>