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

[Vlad Dumitrescu]

Hi,

On Thu, Oct 18, 2012 at 1:48 PM, Joe Armstrong <erlang@REDACTED> wrote:
> Actually I rather like the "apply-hack" - Here's why.
>
> I'll implement a counter module in two different ways:
>
> test2() ->
>     N  = counter2:make(),
>     N1 = N:bump(2),
>     2  = N1:read().
>
>    -module(counter2).
>    ...
>    make() -> {counter2, 0}.
>    bump(K, {counter2,N}) -> {counter2, N+K}.
>    read({_, N}) -> N.

I would say that these tuples are actually an implementation of
passive objects - you could read them as a reference to the object's
class and its state.

They are nice for the reasons Joe and others enumerated and at least one more:
    - the values are immutable

... but I see some drawbacks too:
    - since the values are immutable, one has to keep track of the
"latest" value
    - how would the -spec for such functions look like? How much work
is needed for the type system, dialyzer and other tools to understand
and support this?
    - personally, I like more the "active objects" that processes are;
I would like to be able to use either of them interchangeably. This
would mean that N above could be a pid and we could have "N:bump(2)"
mean "N ! {bump, 2}" and "N:read()" would be "N !! read"... Is the
world ready for that? :-) There was an idea a while ago to have
messages handled in the sender's process, this way the performance
difference becomes much smaller.
    - there is no way to restrict the returned value, so one could
write "bump(K, {counter2,N}) -> {not_a_counter3, N+K}." and change the
object's API [sooner or later someone will come up with a problem
where this solution will make clean, readable and super-nice code].
How would tools (and developers) keep track of which API to apply
when? This is related to the -spec question above.
    - going further with solutions looking for problems, why not use
{[m1, m2, m3], State}, where the call resolution searches the modules
m1, m2 and m3 in this order, so that module "inheritance" needs not
use the error_handler hack?

My personal and humble opinion is that the most rewarding way to
explore is the one started by Joe with UBF (gosh, is it already been
10 years!?): devise a way to specify, control and handle the mesh of
processes and their interactions, both at runtime and statically. This
is what Erlang excels at and I don't see why it should try to emulate
alien features in a feeble way instead of keeping to innovate  and
improve on its strenghts. I can even glimpse material for a PhD or two
:-)

On second thought, the object of my outburst above is largely
orthogonal with the original issue. One is about the language, the
other is more about the runtime. But it feels that if the larger
problem is solved, then it is probable that the other won't be
relevant anymore because there will be other, more erlangish, ways to
solve the same problem.

best regards,
Vlad