Will parameterized modules become an official part of Erlang?
Tue Feb 23 11:31:08 CET 2010
We use parameterised modules occasionally in the internals of QuickCheck.
The reason is that we need to supply a call-back module implementing a
behaviour to a generic module like gen_server or gen_fsm, and the callback
module needs access to parameters that aren't fixed. So we use a
parameterised call-back module and pass that to the generic one. This is the
same kind of example that motivated Richard Carlsson's paper in the first
place... and there isn't any other good way of solving the problem. Making
the parameterised module into a gen_server instead, which has been
suggested, isn't a good solution in this case because it's not
reentrant--you can then only have one "instance" of the parameterised module
at a time. What if you need more?
Taking parameterised modules out of the language would cause us significant
On Mon, Feb 22, 2010 at 4:53 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
> 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.
More information about the erlang-questions