[erlang-questions] Proposal to remove tuple dispatches from Erlang

José Valim jose.valim@REDACTED
Fri Apr 14 14:12:54 CEST 2017

Hi everyone,

I would like to propose to remove "tuple dispatches" from Erlang.

The tuple dispatch is the ability to invoke a function or call
erlang:apply/3 on a tuple as first argument:

Eshell V9.0  (abort with ^G)
1> Var = dict:new().
2> Var:size().

This behaviour is considered by most in the community to be undesired and
confusing, as it obfuscates the meaning of the code and adds indirection.

I have also heard this behaviour made it harder to add some optimizations
to the VM. I would love if someone more knowledgeable on the area could
confirm or deny this. If true, it is also a strong argument to remove such

Another reason for removing it is that the behaviour can be implemented as
needed by adding is_tuple/1 checks to the code or more programmatically by
using a parse transforms (see note 1 at the bottom for a limitation
though). Therefore those who need the behaviour can include it only when
necessary and we don't impose it as a semantics to the whole language (and

I can think of two strategies for removing the behaviour:

1. Clean-cut: the code responsible for tuple dispatching will be completely
removed from the VM and a parse transform will be made available. The parse
transform could be part of Erlang/OTP or a separate repository. This change
is backwards incompatible at the BEAM level. Code that relies on tuple
dispatch without the parse transform on OTP 19 will not work on OTP 20.
However, the parse transform should work with any OTP version, so if the
parse transform is used during compilation, the code is guaranteed to work
on OTP 19 and earlier as well as on OTP 20 onwards.

2. New byte codes: if we don't want to break backwards compatibility at the
BEAM level, I believe our only option is to introduce new bytecodes and a
new apply BIF. Usage of the old BIFs and bytecode could emit warnings while
we phase them out. A compiler option or parse transform should still be
made available if a developer relying on those features wants their code to
run without warnings.

Please let me know if there are other options available,

I will be glad to send patches and implement the required parse-transforms
if this is accepted by the OTP team.

*José Valim*
Skype: jv.ptec
Founder and Director of R&D

Note 1. A parse-transform would be unable to make the following code work
in the same way as today:

erlang:apply(erlang, apply, [dict:new(), size, []])

Although I would consider it highly unlikely to exist so it should not be a
point of contention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170414/e01fcaea/attachment.htm>

More information about the erlang-questions mailing list