[erlang-questions] What is this OOP-like construction doing in Erlang?

[Raphael Korsoski]

Thank you for the detailed explanation!

>From my perspective, having what amounts to an implicit constructor at the
module level is a terrible idea and I'm glad it was removed.

/ Raphael


On Mon, Nov 4, 2013 at 4:46 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> This is history!
>
> So for a long while, Erlang had something called tuple funs, way before
> it had funs of the form 'fun Mod:Fun/Arity' or 'fun Fun/arity'. This
> format would allow you to represent funs as {Module, Fun}.
>
> At some point, Richard Carlsson proposed adding parametrized modules to
> Erlang. This would be done by re-using that functionality at runtime,
> and some compiler trickery so that a module could be declared as
> '-module(Mod, [Arg1, Arg2, ..., ArgN]).', and have a 'new' function
> which would return an opaque '{Mod, Args}' tuple.
>
> All functions of that module would have the implicit 'Args' list of
> argument, allowing to have globally defined arguments, themselves
> instantiated as part of the New function, iirc.
>
> At runtime, the VM would take that tuple call and insert the arguments
> in there.
>
> Then the Erlang community (myself included) got upset as more and more
> projects used that form, because it would introduce subtle
> inconsistencies in expectations -- for example, there was an implicit
> change of function arity of functions that made tracing a pain, and some
> unexpected shadowing when you worked with some functions.
>
> This has been debated a whole lot, and the OTP team ended up making a
> decision where they'd drop the parametrized modules feature from the
> official language (along with packages and whatnot).
>
> This deprecation came with a parse transform being released with the OTP
> team and the addition of the tuple call idiom so that projects using
> parametrized modules wouldn't suddenly be left impossible to upgrade on
> many VMs.
>
> This again didn't make everyone happy, but in the end, it's the
> situation we're in and that's why tuple calls are supported there. We're
> far from the original roots, but that's why it's there.
>
> Regards,
> Fred.
>
> On 11/04, Raphael Korsoski wrote:
> > I was writing some object oriented code over the weekend and upon
> returning
> > to my Erlang coding, I accidentally discovered this rather odd
> construction:
> >
> >     ....
> >     Dict = lists:foldr(...), % dict construction
> >     lists:map(fun(...) -> ... end, Dict:to_list()  <<-- WHUT?!
> >
> > Testing it, it seems that the runtime has the following convention;
> >
> > If T is a tuple, then the Mod:Fun(Args) construction T:Fun(Args) will in
> > fact be interpreted as element(1,T):Fun(Args, T).
> >
> > I would expect something like that in an OO language; although the
> > convention in every language I have used is then to pass the 'self'
> > reference as the _first_ argument. What is this construction doing in
> > Erlang?
> >
> > An example:
> >
> > Erlang R16B01 (erts-5.10.2) [source] [64-bit halfword] [smp:32:32]
> > [async-threads:10] [kernel-poll:false] [systemtap]
> >
> > Eshell V5.10.2  (abort with ^G)
> > 1> T = {erlang, foo, bar, baz}.
> > {erlang,foo,bar,baz}
> > 2> T:tuple_to_list().
> > [erlang,foo,bar,baz]
> > 3>
> >
> > BRs,
> > Raphael K
>
> > _______________________________________________
> > 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/20131104/618b621a/attachment.htm>