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

[Richard Carlsson]

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.

    /Richard