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

[Mikael Pettersson]

Garrett Smith writes:
 > On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
 > > Garrett Smith writes:
 > >  > > We still have time to ditch them :)
 > >  >
 > >  > +1
 > >  >
 > >  > I think the concept is fine, but if they take off they're going to
 > >  > bifurcate Erlang APIs into traditional API modules that take explicit
 > >  > process refs/state and this other breed that somehow gets by without
 > >  > them. Yuck!
 > >  >
 > >  > IMO, this meme (coupling state and behavior) is way too fundamental to
 > >  > have two major variants in a language.
 > >
 > > The parameters in parametrized modules are no more about state than
 > > the free variables in function closures ('fun' expressions) are.
 > >
 > 
 > Okay.
 > 
 > Throw in the fact that you can call functions on a module that have
 > access to these arguments and you have a coupling between these
 > argument values and functionality. Sorry if "state" wasn't pedantic
 > enough for you.

I mentioned fun expressions for a reason, namely that they are pretty
much the same as parametrized modules. Both constructs instantiate
free variables at runtime, resulting in new first-class runtime values.
They only differ in scope: one wraps a single anonymous function, the
other wraps an entire module's worth of functions.

By criticizing this coupling in the case of parametrized modules,
you're effectively also criticizing fun expressions with free variables,
aka lambdas, one of the cornerstones of functional programming.

 > My point is that this pattern is handled adequately without needing
 > parameterized modules and to have two approaches for something this
 > fundamental in a language is bad. I've observed practiced Erlang
 > developers look sideways at mochiweb's Req:respond(...), look confused
 > for a moment, and then conclude that it must be this unofficial
 > feature called parameterized modules. What's the point of this? It's
 > not unlike stumbling on the use of the process dictionary: "ah,
 > *that's* how they're doing it!" IMO, this should be avoided wherever
 > possible - and it's very avoidable in the case of parameterized
 > modules.

I don't know that 'this pattern' and 'this fundamental' refer to, but
mochiweb/OTP/gen_server/etc are just libraries. They use the Erlang
language but do not define it. They can invent whatever APIs they like,
however sane or insane, clear or confusing, old-fashined or bleeding-edge.
You're not required to use them, and if sufficiently many agree with you
better APIs will be created and the bad ones will die. End of problem.