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

[José Valim]

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*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

On Fri, Apr 14, 2017 at 7:32 PM, Richard Carlsson <
carlsson.richard@REDACTED> 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 <v@REDACTED>:
>
>> 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 <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
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170416/524ba87f/attachment.htm>