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

[赵 汉]

This  is  really  cool   for  both  erlang  and  elixir
defmodule MyBianry   do
def size({_, binary}) do
:erlang.size(binary)
  end

end

defmodule MyTuple  do

def size({_, tuple} ) do
:erlang.size(tuple)
  end

end

defmodule MyList   do

def size({_, list}) do
length(list)
  end

end

iex(24)> var={MyBianry, <<1,2,3,4>>}
{MyBianry, <<1, 2, 3, 4>>}
iex(25)> var.size
4
iex(26)> var={MyTuple, {1,2,3,4}}
{MyTuple, {1, 2, 3, 4}}
iex(27)> var.size
4
iex(28)> var={MyList, [1,2,3,4,5,6]}
{MyList, [1, 2, 3, 4, 5, 6]}
iex(29)> var.size
6



iex(9)> c "myList.erl"
[:myList]
iex(10)> c "myBinary.erl"
[:myBinary]
iex(11)> c "myTuple.erl"
[:myTuple]
iex(12)> :myList.msize({:a,[1,2,3,4]})
4
iex(13)> var={:myList,[1,2,3,4]}
{:myList, [1, 2, 3, 4]}
iex(14)> var.msize
4
iex(15)> var={:myBinary,<<1,2,3,4>>}
{:myBinary, <<1, 2, 3, 4>>}
iex(16)> var.msize
4
iex(17)> var={:myTuple,{1,2,3,4}}
{:myTuple, {1, 2, 3, 4}}
iex(18)> var.msize
4
iex(19)>


发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用

发件人: José Valim<mailto:jose.valim@REDACTED>
发送时间: 2017年4月14日 20:13
收件人: Erlang<mailto:erlang-questions@REDACTED>
主题: [erlang-questions] Proposal to remove tuple dispatches from Erlang

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170427/0209c753/attachment.htm>