[erlang-questions] Re: Will parameterized modules become an official part of Erlang?

[Geoff Cant]

Zubair Quraishi <zubairq@REDACTED> writes:

> I disagree because the fact that parameterised modules are used only
> "internally" in OTP tells me that they "could" be removed. I say this
> because removing parameterised modules would not break any client libraries
> for OTP, as the internals of OTP could just be changed.
>
> Is there anyone from Ericcson who could shed light on this, or is it simply
> a "risk" to use parameterised modules?
>
> On Sun, Feb 21, 2010 at 12:25 PM, Rapsey <rapsey@REDACTED> wrote:
>
>> Not a large chance of that. It's used in a number of libraries including
>> OTP
>> internally.

The only use of parameterized modules in OTP is in the test suites, and
most of these appear to simply be testing that various tools can cope
with parameterized modules:

lib/compiler/test/pmod_SUITE_data/pmod_basic.erl:-module(pmod_basic, [Props]).
lib/stdlib/test/dict_test_lib.erl:-module(dict_test_lib, [Mod,Equal]).
lib/stdlib/test/epp_SUITE_data/pmod.erl:-module(pmod, [Props]).
lib/stdlib/test/erl_eval_helper.erl:-module(erl_eval_helper, [Base]).
lib/stdlib/test/erl_expand_records_SUITE.erl:    Test = <<"-module(param, [A, B]).
lib/stdlib/test/erl_expand_records_SUITE.erl:    Test = <<"-module(guard, [A, B]).
lib/stdlib/test/erl_lint_SUITE.erl:    Abstr = <<"-module(lint_test, [A, B]).
lib/stdlib/test/erl_pp_SUITE.erl:    ?line ok = pp_forms(<<"-module(m.p, [A,B]). ">>),
lib/stdlib/test/erl_pp_SUITE.erl:    ?line ok = pp_forms(<<"-module(m, [Aafjlksfjdlsjflsdfjlsdjflkdsfjlk,"
lib/stdlib/test/sets_test_lib.erl:-module(sets_test_lib, [Mod,Equal]).
lib/stdlib/test/shell_SUITE.erl:    Contents = <<"-module(parameterized, [A]). "
lib/tools/test/xref_SUITE.erl:    Test = <<"-module(param, [A, B]).

We still have time to ditch them :)


Parameterized modules seem to be mainly useful as a way of having the
compiler pass around what would otherwise be a state argument (module
callback data) for you. Given that the result is still functional, you
still have to return {Result, UpdatedParamModule} if you want to alter
any of the module parameters, I don't see it improving existing
gen_server style callback APIs. Code that needs to update module
parameters is in fact less readable than if a state record had been used
as there's no syntax for selectively updating parameters.

Module parameters are simply hidden function arguments. To me, this
reduces the readability of the code as there's now another place to look
for data that will affect function behaviour.

Another problem with them is that there's no support for pattern
matching the module parameters as there is for function arguments.


The main use of parameterized modules I've seen in the wild is the
mochiweb_request module. While this use of parameterized modules does
slightly improve client code by shortening mochiweb_request:Method(Req,
Args) to Req:Method(Args), it does make the code less grepable for uses
of mochiweb_request unless you follow the convention of always calling
the request module 'Req'. 

The mochiweb_request term (object?) does need to go through certain
state transitions such as reading the request body. Unfortunately the
API doesn't return an updated mochiweb_request, it uses the process
dictionary to memoize this. The resulting term/object is now
process-specific and behaves surprisingly differently to regular erlang
opaque data structures when passed between processes.

The API doesn't seem to be better for having used parameterized modules.

If the API did return an updated module, the mochiweb_request code would
be littered with calls to ?MODULE:new(Arg, Arg, Arg, UpdatedArg, Arg)
and the client could would have all the {Result, UpdatedReq} =
Req:Method(Args) code that a regular gen_server style callback interface
has.


I would gladly reconsider my somewhat harshly critical position on
parameterized modules if shown a clear example of how their use
improves the readability or expressiveness of code. Until then I would
urge that they didn't become an official part of the Erlang language.

Cheers,
-- 
Geoff Cant, Erlang curmudgeon and OTP-fundamentalist.