7

A similar question was asked Parameterised Modules in Erlang, it is about "what". My question is about "why"?

OTP Technical Board - Decisions affecting R16 contains the board decision about this issue, but I don't know the reason behind the decision.

Stateful Module in Programming Erlang 2ndEdition by Joe Armstrong introduces this feature in detail, but I don't see the author's attitude.

If we read the official document Function Calls, we see this feature is deliberately skimmed. In fact, the official document strongly discourages using this feature, refer to efficiency function calls. If so, why Joe Armstrong mentions such feature in his book?

I think this feature is awesome. As the above book mentioned, my client code could be like below

Obj:find(Key),
Obj:is_key(Key),

Then, we don't care whether Obj is created by dict:new(), or gb_tree:new(), unfortunately, dict and gb_tree do not share a consistent interface, e.g. we have gb_tree:lookup instead of gb_tree:find.

Community
  • 1
  • 1
wcy
  • 875
  • 11
  • 12
  • I am finding this feature very useful in implementing some boundary modules. In production code they are just the normal module but for tests there is a fake boundary, which often has state so I use a tuple module. something like in this question http://stackoverflow.com/questions/32860342/define-a-constant-module-in-elixir/32861188#32861188 – Peter Saxton Sep 30 '15 at 08:35

2 Answers2

7

I can't tell you what the discussion was within the Great Cabal That Controls Everything, but I can tell you a few reasons why I never have considered using this feature:

  1. It doesn't fit. Erlang is functional and this is a weird introduction of OOP-style structs-that-have-arms-and-legs sort of thing. I don't like my code to clash with itself.

  2. It introduces syntactic complexity and semantic abiguity but grants me no new superpowers.

    • Complexity:

      1. "Is attribute X of Foo equal to 10 or 20 right now?"
      2. "Why do I write dict:is_key(Value, Thingy) here and then Thingy:is_key(Value) over there?
      3. "Do I really want to encounter code like dict:is_key(Key, Foo:get_value(Key2)) all the time?"
      4. I already have an army of processes designed to do just this and move the complexity of state out of the process code and into the world of asyncronous messages (in code I can deal with an isolated snapshot of time within a single call of a function)...
      5. If I really need this isn't that what the process dictionary was for?

    • Ambiguity:

      1. "Is this a 'thing' I'm calling a method of, or a module function I'm calling?"
      2. "Wait, wasn't this supposed to be functional?"
      3. "Is it OK to put that in a closure and send it off somewhere else? What if 'somewhere else' is another node? Do I have to start caring about that suddenly?"

  3. This introduces opaque state (bad) instead of an ADT (good, and something we already have).

  4. Nobody uses this, so why waste effort supporting it, especially considering the corner cases it might bring up. That's support overhead and effort I would rather see go into features that we all do use.
  5. The "gain" here is only perceived as a benefit to people who can't bear to part with Java-isms. There isn't much difference between Foo:is_key(Key) than dict:is_key(Key, Foo). Other than the fact that I am certain on first reading, even in a complete absence of context, that the data object being operated upon in the second version is definitely a dict.

Erlang's symbol assignment (aka "single assignment") is great, why destroy that?

zxq9
  • 13,020
  • 1
  • 43
  • 60
  • The feature does not break "single assignment", Joe suggest something like `D2 = D1:insert(K,V)`, this is quite different with traditional OO language, `D1` is unchanged. This feature enable us to write more general library, e.g. `A=[dict:new(), gb_tree:new()]` , later on, we can pass A to a library function, e.g. `has_car(A) -> lists:filter(fun (D) -> D:is_key(car) end, A)`. Anyway, I agree your points, like, "it doesn't fit", "ambiguity", "opaque state" etc. – wcy Aug 12 '15 at 10:48
  • @wcy I must be mistaken about single-assignment, then. I recalled seeing some code (maybe an early concept that wasn't implemented?) where something like `ok = D:set_foo(10), 10 = D:get_foo(), ok = D:set_foo(20), 20 = D:get_foo()` worked the way it would in an OOP language -- which struck me as asking for a whole ball of trouble. Anyway, *with* single assignment I think this sort of OOP-ish syntax is even more pointless than with mutability. Just a bad fit to bring a syntax with a semantics we all know well from another paradigm into this realm, but change arbitrary details of it. – zxq9 Aug 12 '15 at 13:03
4

There are other issues as well:

  • When I write Foo:bar(42) where Foo maybe either just a module name or maybe a tuple module but I don't see the difference. This means I might be calling either bar/1 or bar/2.

  • I can call the same function in different ways.

  • It can be difficult to relate errors in functions to the call as the arity is different.

And more. I think it is a shame that we didn't get rid of tuple modules when we got rid of parametrised modules. They were originally just a hacky way of implementing parametrised modules.

rvirding
  • 20,848
  • 2
  • 37
  • 56