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

[Tony Rogvall]

> On 14 apr 2017, at 14:12, José Valim <jose.valim@REDACTED> wrote:
> 
> 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().
> {dict,0,16,16,8,80,48,
>       {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
>       {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}}
> 2> Var:size().
> 0
> 

I think it is calling erlang:apply/2, the above code is called like

> apply({Var,size}, []).
0

This is, interestingly enough, equivalent to

> erlang:apply(element(1,Var), size, [Var]).
0

But maybe that was what you meant?

I think this once was part of the parametrized module stuff, this is now gone.

Utterly confusing an strange.

/Tony

> 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 behaviour.
> 
> 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 ecosystem).
> 
> 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
> www.plataformatec.com.br
> 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.
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170414/06abd56f/attachment.bin>