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

[Richard Carlsson]

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/20170414/b0412cab/attachment.htm>