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

[Loïc Hoguin]

I'm all against using this feature personally, though removing is a bit 
harsh considering there's still a lot of code relying on it.

Something is unclear to me though. Why do YOU want to remove it? Will it 
improve something for you?

On 04/14/2017 02:12 PM, José Valim 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
>
>
> 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 <http://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
>

-- 
Loïc Hoguin
https://ninenines.eu