[erlang-questions] about the use of parametrized modules

[Frédéric Trottier-Hébert]

On 2011-01-13, at 19:05 PM, Robert Virding wrote:

> ----- "Paolo Negri" <paolo.negri@REDACTED> wrote:
> 
>> Looking at the misultin source code [1] I noticed the use of a
>> parametrized module, after googling about it I came to the conclusion
>> that there's something controversial about them [2] and that it seems
>> to be appealing mainly people coming from OO background [3].
>> 
>> I'm considering applying this technique but before doing so I'd like
>> to know if isn't a deprecated approach and in general if it's
>> considered a bad practice.
>> I'm curious because I don't remember seeing parametrized modules used
>> in Joe Armstron's or Francesco Cesarini's books.
> 
> The main reason they don't mention it is because it is still only experimental and not part of the language. It is very controversial and often discussions about it pop up in erlang-questions. I personally don't like it.
> 
> Robert
> 
> -- 
> Robert Virding, Erlang Solutions Ltd.
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 
I will echo the sentiment. My reasons for disliking parametrized modules have been written in a stackoverflow.com rant before (http://stackoverflow.com/questions/2291155/what-alternatives-are-there-to-parameterised-modules-in-erlang/2291394#2291394), but I'll rehash them here.

As far as I know, parametrized modules were first added to the language as a way to deal with services that would take callbacks, to which you need to add your own state, except that:
- The server doesn't allow to pass specific extra arguments
- The server wants a module instead of a closure (frequently the case)
- Meta-programming or hardcoding different variations is too much of a burden
- Holding some kind of reference to global state is an annoyance and usually a code smell.

(see: http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf)

In these case, parametrized modules would allow you to encapsulate some state along with the callback module and would allow you to solve that problem. The current implementation, as far as I know, depends on the old way to call funs with a tuple and arguments that has been deprecated for quite a while now. The mechanisms to handle it were apparently still in the VM and used to let parametrized modules be. Whether parametrized modules are the right solution to that problem or not is not really my judgment call to make, given I can't think of a better approach at the moment.

The problem I have with parametrized modules is that they are used in many ways except the one for which they were [unofficially] introduced into the language. A lot of people use them as a pseudo-object or global variables (I'm looking at you, chicagoboss), or as a way to have some syntactic sugar around passing a state parameter to callback functions (Now I'm looking at you, mochiweb).

This, in my opinion, is shoehorning OO patterns into Erlang, in a way that confuses many newcomers (we see them from time to time on IRC). It also uselessly adds new semantics to the language: is the new/N function safe to use for other reasons? Why are there 3 ways to call modules now (one returns an updatable data structure, one doesn't because a process holds it, and one returns a new module instance)?

It also causes ghosting issues , because the parametrized variables act like global variables in the module, which you might overwrite with function arguments or thought could be used safely in pattern matches. The 'case ... of' expression comes to mind right now -- people have complained a bit about how its scoping rules are weird; parametrized modules add to that, because you can now potentially pattern match on variables that might or might not work with your current patterns depending on how you called them, and this without any clue of where it's coming from (especially for large modules) unless you analyse it later.

I have frequently avoided them, but earlier this week, someone on IRC complained that parametrized modules basically messed up a lot of contracts and angered Dialyzer because of it. If using them means type-checking your code is harder (or you have to accept errors all the time), I just want to pass my turn.

In my opinion, they are used as a shortcut so you type less, but in the long run, I firmly believe it does it at the cost of readability, ease of understanding code and ease of maintenance while making Erlang more complex as a language.

/Rant 

--
Fred Hébert
http://www.erlang-solutions.com