[erlang-questions] Re: Will parameterized modules become an official part of Erlang?
Tue Feb 23 00:35:29 CET 2010
On Mon, Feb 22, 2010 at 4:53 PM, Mikael Pettersson <> wrote:
> Garrett Smith writes:
> > On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson <> 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.
I'm not criticizing it in principle. I have personally chosen to not
use parameterized modules primarily because they make my APIs look
different from the rest of the OTP apps. Secondarily, I'm not a fan of
the "free variables" they hide. And I haven't needed to.
> > 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.
APIs die? Gosh I've seen not a few, really bad ones, live on and on.
You may then be more comfortable with the range of naming and API
"conventions" used in Erlang than I am. IMO, it makes it difficult to
design an Erlang API because, at times, there's no clear/obvious cue
from Erlang/OTP. It also makes it hard to remember things. There've
been a few rants lately here on this topic.
Of course, this is true of any language/framework/platform - it's
impossible to tightly control every aspect of its evolution. This
isn't even necessarily a problem. But the more "ways of doing
something" there are in a system, the harder it is to learn that
I recognize this is not a universal, incontrovertible opinion :) Some
developers prefer flexibility and like more language features. I tend
to prefer fewer features/options provided I can get the job done.
More information about the erlang-questions