What is even more sad, I've been told that tuple modules will likely be killed in the name of performance.<br><br><br>Earlier this year I conducted an experiment and sent its proceedings to Björn and this mailing list, but I have never heard back from him.<br><br><br>Here it is again:<br><br><br>"I actually just did a totally unscientific test. I took the maint<br>branch, and ran 10,000,000 Mod:fn() calls where Mod was passed from<br>another function call and was just an atom. I ran it on maint, and on<br>my Mac Pro timer:tc clocked 446983 (that's 0.446 seconds).<br><br>After that, I brutally removed tuple call support from apply and<br>fixed_apply BIFs in beam_emu.c, making `if (is_not_atom(module))` go<br>straight to error label. I also removed `this` variable which was used<br>in those checks because there was no need for it anymore.<br><br>I re-ran the test, and timer:tc clocked 440680 and around.<br><br>So, the runtime cost difference was about 6000 microseconds, or 0.006<br>seconds, for 10 million calls. If I am not mistaking, this is a 1.35%<br>speedup on something as low cost as about 0.0446 microseconds per call<br>(or 0.0440 microseconds per call without support for tuple calls).<br><br>Is it this big of a difference to support the removal? What if we made<br>tuple calls a documented feature? I'd be glad to write an EEP to<br>support it."<br><br>On Friday, October 12, 2012 10:35:26 AM UTC-7, Yurii Rashkovskii wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">From what I learned earlier this year, tuple modules have a bleak future as well:<div><br>===<br><br>[1] > But I was wondering if there's any word out about the fate of tuple<br>> modules? The ones like {erlang}:element(1). Are they expected to be<br>> kept around? (I certainly hope they are :)<br>><br><br>No, we don't expect to keep them.<br><br>As pointed out by others, "tuple modules" is just an implementation<br>detail of parameterized modules (which is an experimental feature).<br><br>We have not reached a decision yet, but in the future we expect<br>we will do one of two things:<br><br>* Remove parameterized modules completely from the compiler<br>and run-time system.<br><br>OR<br><br>* Implement parameterized modules properly by creating a new<br>data type, both to allow better type checking by Dialyzer, and<br>to possibly improve performance.<br><br>/Björn<br><div><font face="arial, sans-serif">====<br></font><br>On Friday, October 12, 2012 1:04:52 AM UTC-7, Gleb Peregud wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I believe that someone from OTP team mentioned that the parametrized
<br>modules are to be deleted, but tuple modules will stay. Essentially
<br>this will mean that instead of writing:
<br>
<br>-module(person, [FirstName, LastName]).
<br>-compile(export_all).
<br>first_name() ->
<br>  FirstName.
<br>
<br>You will have to write:
<br>
<br>-module(person).
<br>-record(person, {first_name, last_name}).
<br>-compile(export_all).
<br>new(FirstName, LastName) ->
<br>  #person{first_name = FirstName, last_name = LastName}.
<br>first_name(Person) ->
<br>  Perosn#person.first_name.
<br>
<br>but you will still be able to do:
<br>
<br>   Person = person:new("Joe", "Armstrong").
<br>   Person:first_name().
<br>   "Joe"
<br>   case Person:save() of
<br>       {ok, SavedPerson} -> % do something ...
<br>       {error, ValidationErrors} -> % do something else ...
<br>   end.
<br>
<br>So from point of view of readability there will be no change,
<br>althought the amount of code in the model module (person.erl) will
<br>slightly increase.
<br>
<br>Please correct me if I am wrong.
<br>
<br>Cheers,
<br>Gleb
<br>______________________________<wbr>_________________
<br>erlang-questions mailing list
<br><a>erlang-q...@erlang.org</a>
<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br></blockquote></div></div></blockquote>