Parameterised Modules in Erlang

问题:

I was going through mochiweb source code and got to see something i never used before. The module declaration especially in mochiweb_request and mochiweb_response modules found in the mochiweb http library. Here is how the module begins:

-module(mochiweb_request,[Socket, Method, RawPath, Version, Headers]).
-author(...).

Then in the module you see get(socket) -> Socket;get(method)-> Method; ....
This has confused me. When i tried getting the module info of one of these such module, the compiler had added something: {abstract,true} in the return to:
mochiweb_request:module_info().. Infact, their documentation refers to these modules as abstract modules.

I have searched google and found a paper on parameterised modules: the link is so big but am sure you will get the paper if u follow on here

These modules cannot be called directly but are called through instances of them selves. It makes modules behave as though they were funs. I have come to realise that its an unofficial feature in the runtime system. What confuses me is that the mochiweb guys are using it well!. In a mochiweb module, you will find your self writing:

loop(Req,_DocRoot)->
    "/" ++ Path = Req:get_path(),
    Body = Req:recv_body(),
    Method = Req:get(method),
    ...,
    ....,
    Response = Req:ok({"text.html;charset=utf-8",[],chunked}),
    Response:write_chunk("Some text here....."),
    ...

Trying to io:format("\n\t Req = ~p~n",[Req]) reveales a complex data structure (a tuple) whose element(1,Req) == mochiweb_request. It is interesting!?!!!?

Question 1 is: Is it stable to use in production for now or i can wait till it is made official?

Question 2 is: How did the mochiweb guys get the confidence of using it, if it is not yet official?

Question 3: Why is it not yet official? (because, to me, it brings some Object Oriented features in)

Question 4: Is there anyone out there who has used it also? In which cases has he/she used these parameterised modules? Why? Can you point us there to see or post a link to some source code so we can find out more on this feature?

Last Question: No where in the Erlang Docs have i found this feature talked about. No text book, Not even home. So how did those who have used it already find out how and why to use it? Has it already been included in the commercial version of the Erlang Run time system found here?

回答1:

Question 1 is: Is it stable to use in production for now or i can wait till it is made official?

It is very stable for production use and has been for some time now. It is not part of the official standard.

Question 2 is: How did the mochiweb guys get the confidence of using it, if it is not yet official?

You will have to ask the mochiweb guys for this. Perhaps they believe they can quickly change it if it was pulled.

Question 3: Why is it not yet official? (because, to me, it brings some Object Oriented features in)

Because it is littered with controversy. It is not clear what benefits it bring to the language and how it makes stuff easier to do, so P. Modules have its proponents and opponents. Hence, the current standpoint is that it is part of the implementation, so people can play with it and see if they feel it makes their code easier to read and write. The non-officiality means it can be pulled without deprecation though, and it seems as if the Erlang guys reserve that right.

personal bias: I kind-of like it, but I won't ever be using it for getting OOP-features into Erlang. OOP is an ugly behemoth of utter crap that has no place in programming ever. It is just misery that will haunt your programs until they are rotten to the core, walking around like zombies and being mad. The only solution at that point is the shotgun. Rather, I'd like to use it as ML-style functors - which is more static in I feel it matches the idioms of Erlang better.

Last Question: No where in the Erlang Docs have i found this feature talked about. No text book, Not even home. So how did those who have used it already find out how and why to use it? Has it already been included in the commercial version of the Erlang Run time system found here?

The author presented the thing at an Erlang conference some years ago. Since then it has been a combination of word-of-mouth and so on.

回答2:

Question 1 is: Is it stable to use in production for now or i can wait till it is made official?

It was removed in R16B. From the README:

OTP-10616 The experimental feature "parameterized modules" (also called "abstract modules") has been removed. For applications that depends on parameterized modules, there is a parse transform that can be used to still use parameterized modules. The parse transform can be found at: http://github.com/erlang/pmod_transform

Question 2 is: How did the mochiweb guys get the confidence of using it, if it is not yet official?

Use of parameterised modules has been removed from Mochiweb, starting from release 2.4.0, though calls to formerly parameterised modules still look the same, as the implementation mechanism for parameterised modules (tuple modules) is kept for backwards compatibility. even though support for tuple calls were removed from the compiler in Erlang/OTP 21.0:

OTP-14497 Application(s): compiler, erts

* POTENTIAL INCOMPATIBILITY *

Support for "tuple calls" have been removed from the run-time system. Tuple calls was an undocumented and unsupported feature which allowed the module argument for an apply operation to be a tuple: Var = dict:new(), Var:size(). This "feature" frequently caused confusion, especially when such call failed. The stacktrace would point out functions that don't exist in the source code.

For legacy code that need to use parameterized modules or tuple calls for some other reason, there is a new compiler option called tuple_calls. When this option is given, the compiler will generate extra code that emulates the old behavior for calls where the module is a variable.

Mochiweb now uses the tuple_calls compiler option for this type of code to keep working.

Question 3: Why is it not yet official? (because, to me, it brings some Object Oriented features in)

From the Technical Board decision announcing the end of parameterised modules:

The board acknowledges that a lot of software relies on this feature although it's always been experimental. The current form of the implementation is not acceptable and the parameterized modules as such has never been accepted as a feature in the language. The feature is also not compatible with for example module-fun's and is not fully integrated with the rest of the tools in OTP.