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

[Jesse Gumm]

For some light reading on a rainy day, here are a few other largish
threads from erlang-questions related to pmods:

https://groups.google.com/forum/#!topic/erlang-programming/PbvKUqXQ9II

https://groups.google.com/d/msg/erlang-programming/3s_6jTVUW5c/EHyIOhWpAcMJ

-Jesse

On Mon, Nov 4, 2013 at 11:06 AM, Raphael Korsoski <psidrinal@REDACTED> wrote:
> 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
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm