Will parameterized modules become an official part of Erlang?

[John Hughes]

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 
pain.

John


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.