[erlang-questions] OTP-9649 and further changes

[Yurii Rashkovskii]

Björn,

I wanted to follow up on this. I am investigating this whiole issue
(as I really would love to keep tuple calls) and I would like to know
whether you have any numbers on how significant the speed impediment
of this feature is (the run-time cost incurred in apply/3) that you
mentioned earlier? Do you have any comparisons?

Yurii

On Mon, Jan 23, 2012 at 11:22 PM, Björn Gustavsson
<bgustavsson@REDACTED> wrote:
> 2012/1/24 Yurii Rashkovskii <yrashk@REDACTED>:
>> Björn,
>>
>> Is there any way tuple module calls can be separated from parametrized
>> modules and subsequently documented and become part of standard
>> Erlang?
>>
>
> Perhaps.
>
> The problem with the current implementation of "tuple modules"
> is that the M in apply(M, F, A) and M:F(...) has a strange type, i.e. M can
> be either an atom or a tuple. Unless we implement parameterized modules,
> we want M to be only an atom. (There is a run-time cost in the
> implementation of apply/3 to allow parameterized modules/"tuple modules",
> and parameterized modules prevented an optimization I wanted to do in the
> compiler for R15B.)
>
> We might consider an alternative implementation of "tuple modules"
> that does not use apply(M, F, A) or M:F(...), using either new BIFs or new
> syntax. (Example: tuple_module_apply(M, F, A) could behave as apply/3
> currently behaves, or alternatively only allow M to be a tuple. This is not
> a serious suggestion, just an example to make it clear what I mean.)
>
> I suggest that you write an EEP.
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB