[erlang-questions] Proposal to remove tuple dispatches from Erlang
Fri Apr 14 14:19:55 CEST 2017
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().
> 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
> 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
More information about the erlang-questions