Proposal to remove tuple dispatches from Erlang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal to remove tuple dispatches from Erlang

José Valim-2
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
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Loïc Hoguin-3
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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Tony Rogvall-2
In reply to this post by José Valim-2

> On 14 apr 2017, at 14:12, José Valim <[hidden email]> 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

José Valim-2
In reply to this post by Loïc Hoguin-3
Thanks for the input Loïc. When you say removing it is harsh, do you mean removing it immediately in favor of a parse transform (implementation 1) or are you also against implementation 2 which would be backwards compatible at BEAM level and allow the feature to be slowly phased out through the years?

Regarding my personal reasons, they have all been listed in the original email. It is a style that I believe should be discouraged, as it can be implemented manually when desired, especially if it is in the way of further improvements at the VM level (pending confirmation). Elixir and Erlang should be equally affected by the proposed changes (as Elixir targets the Erlang Abstract Format).
--


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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Fred Hebert-2
In reply to this post by José Valim-2
On 04/14, José Valim wrote:
>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.
>
>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.
>

One thing to consider is that this code is a remnant of parametrized
modules, which have been removed back in 2012. See https://web-beta.archive.org/web/20121019180935/http://www.erlang.org/news/35


> To allow for source code compatibility, the board decides to only
> remove the syntactic support for parameterized modules. This means:
>
> * Apply with tuple modules will be retained, supported and properly documented.
>
> [...]
>
> * The parser will accept the syntax for implementation of
>   parameterized modules [...]
>
> * A parse_transform handling source code implementing a parameterized
>   module will be published in the public domain, free to use and
>   include in any package needing it. It will however not be part of OTP.
>   As it uses supported and documented functionality, it will however
>   be expected to work for forthcoming releases as well, or at least
>   to be possible to adopt to forthcoming releases.

This is to say the OTP team made a commitment to supporting tuple calls
as a way to remove parametrized modules and keep the code working.

Removing tuple calls must at the very least ensure a seamless transition
to keep working with the parametrized module parse transforms, and
moreover have the guarantee that it will "be expected to work for
forthcoming releases" because it "uses supported and documented
functionality".

Regards,
Fred.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Valentin Micic-2
In reply to this post by Tony Rogvall-2
I wonder if Fun implementation  (e.g. F=fun(..) -> end) relies on "tuple dispatches".

V/

On 14 Apr 2017, at 2:33 PM, Tony Rogvall wrote:

>
>> On 14 apr 2017, at 14:12, José Valim <[hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Richard Carlsson-3
The original prototype implementation of funs did indeed use tuples as the representation. Later, funs became a proper built-in data type. The intention was of course for abstract modules to go the same path.


        /Richard

2017-04-14 15:04 GMT+02:00 Valentin Micic <[hidden email]>:
I wonder if Fun implementation  (e.g. F=fun(..) -> end) relies on "tuple dispatches".

V/

On 14 Apr 2017, at 2:33 PM, Tony Rogvall wrote:

>
>> On 14 apr 2017, at 14:12, José Valim <[hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

José Valim-2
Thanks everyone for the feedback. It is clear now that backwards compatibility must be considered. I will work on a new proposal that focus on those aspects.



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

On Fri, Apr 14, 2017 at 7:32 PM, Richard Carlsson <[hidden email]> wrote:
The original prototype implementation of funs did indeed use tuples as the representation. Later, funs became a proper built-in data type. The intention was of course for abstract modules to go the same path.


        /Richard

2017-04-14 15:04 GMT+02:00 Valentin Micic <[hidden email]>:
I wonder if Fun implementation  (e.g. F=fun(..) -> end) relies on "tuple dispatches".

V/

On 14 Apr 2017, at 2:33 PM, Tony Rogvall wrote:

>
>> On 14 apr 2017, at 14:12, José Valim <[hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal to remove tuple dispatches from Erlang

Kostis Sagonas-2
In reply to this post by José Valim-2
On 04/14/2017 02:12 PM, José Valim wrote:

> Hi everyone,
>
> I would like to propose to remove "tuple dispatches" from Erlang.
>
> ... <SNIP>
>
> 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. ... <SNIP>
>
> 2. New byte codes:

FWIW, I strongly support option #1 above.

I think it's about time that "features" that make Erlang weird get
eliminated from the implementation.  It took me several years to
convince the OTP team that they should eliminate tuple-funs from the
implementation.  They finally did and, unsurprisingly, the world has not
stopped turning, nor did anybody decide to stop using Erlang for what it
is good at, simply because it had no "tuple-funs" any longer.  On the
contrary, I think we have a slightly better language since their
removal.  Similarly, I think it will become slightly better with the
removal of "tuple dispatches".

Anyway, that's my .02.

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

答复: Proposal to remove tuple dispatches from Erlang

赵 汉
In reply to this post by José Valim-2

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 邮件应用

 

发件人: [hidden email]
发送时间: 2017414 20:13
收件人: [hidden email]
主题: [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

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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...