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

[Joe Armstrong]

Actually I rather like the "apply-hack" - Here's why.

I'll implement a counter module in two different ways:

Here's the code that uses the counter(s)

-module(test).
-compile(export_all).

test1() ->
    N  = counter1:make(),
    N1 = counter1:bump(N, 2),
    2  = counter1:read(N1).

test2() ->
    N  = counter2:make(),
    N1 = N:bump(2),
    2  = N1:read().

test1() is traditional Erlang. test2() uses the apply-hack.

test2() is shorter than test1() and there are fewer arguments to bump
all of which is good. We can't at a glance see what N and N1 (in
test2()) are but the same is true
of funs. We often have no idea what F is before we call F(...) it's
just an argument that has come from somewhere.
At least with "tuple-module" we can print them to see what they are.

The corresponding counter code is:

  -module(counter1).
  ...
  make()     -> 0.
  bump(N, K) -> N+K.
  read(N) -> N.

and

   -module(counter2).
   ...
   make() -> {counter2, 0}.
   bump(K, {counter2,N}) -> {counter2, N+K}.
   read({_, N}) -> N.

It seems to me that tuple modules make for shorter client code (a good thing)
and more verbose implementations.

In certain circumstances - they are very useful.

I don't think they should be overused - but I rather like them

Cheers

/Joe


On Tue, Oct 16, 2012 at 11:45 PM, Richard Carlsson
<carlsson.richard@REDACTED> wrote:
> On 2012-10-16 23:29 , Robert Virding wrote:
>>
>> Doesn't this mean that now the syntax for parametrised modules is
>> still there but becomes meaningless? Or rather it will mean whatever
>> the writer of a module chooses it to mean. That really won't
>> encourage clarity. Or what am I missing?
>
>
> It also seems ass-backwards to me that the syntax will be dropped, but the
> hack that we used for the proof-of-concept implementation will be
> immortalized as "tuple modules". Drop the parameterized modules if you like,
> but don't make the apply-hack a documented feature; the old {M,F} was bad
> enough.
>
>     /Richard
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions