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