[erlang-questions] Pmods, packages, Unicode source code and column numbers in compiler - what will happen in R16?

[Loïc Hoguin]

On 10/17/2012 01:00 AM, Richard Carlsson wrote:
> On 2012-10-17 00:29 , Richard Carlsson wrote:
>> On 2012-10-17 00:09 , Robert Virding wrote:
>>> I agree. Do it properly or get rid of it.
>>
>> On second thought, there is one advantage to documenting this
>> representation: there can be no doubt that when you make a call through
>> a tuple {m,...}:f(...), you'll call the latest version of the module. We
>> had originally planned to make pmods an opaque datatype, like funs, but
>> unlike funs we didn't want to be bound to the module version used to
>> create the instance. Keeping the representation open should make it
>> clear what it is you're getting. But then don't remove the language
>> support - make it work throughout the toolchain instead.
>
> For the record, the bad part about making a representation like this
> public is that it takes implementation details that happened to make
> sense for the underlying platform at the time (BEAM), and makes it
> impossible to change them later on. In this case, such implementation
> details are that the tuple contains exactly the module name followed by
> the hidden parameters, in order. No additional fields can be added in
> future versions. Also, the calling convention becomes fixed so that the
> module tuple itself must always be passed as the last parameter.

Now what if the tuple call support was removed and was simply replaced 
in the parse transform by code similar to the following?

if is_tuple(Var) -> M = element(1, Var), M:fun();
    true -> Var:fun()
end

It would still work, it would cleanup OTP completely, and I don't think 
the performance loss would be too bad. After all, people caring *this 
much* about performance wouldn't use tuple calls to begin with, right?

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu