[erlang-questions] Parameterized module initialization

[Richard Carlsson]

On 06/27/2012 06:01 PM, Tim Watson wrote:
> Yes, wouldn't existing stuff like xref and dialyzer and cover and so
> on, require less patching this way also?
>
> On 27 Jun 2012, at 10:18, Anthony Ramine<n.oxyde@REDACTED>  wrote:
>
>> I find it way saner for a parameterized module to be a mapping from
>> modules to modules than to be a way to encapsulate some arbitrary
>> terms.
>>
>> I may be wrong but I think that it would be easier to implement and
>> reason about them in a non leaky way if their arguments were only
>> module names.

In a statically typed language like ML, restricting the type of 
structure parameters to also be structures makes sense. It means that 
the functor is something that takes one or more smaller structures 
implementing some specific interfaces (classic examples are generic data 
types like a queue), and returns a new, larger structure that builds on 
the given structures. As far as I know, functor instantiation is done at 
compile time only, but using separate compilation for each involved 
structure. This basically means that instantiating a structure by 
another structure can be done by patching code pointers (and nobody 
needs to pass around an object/vtable). Since the signatures have been 
checked, nothing can "go wrong". Allowing other data types than 
structures as parameters would make separate compilation difficult 
(compare C++ templates). But it also means that the only way to 
parameterize a structure over a constant - say, the gravitational 
constant for a simulation - is to create a separate GravityConstant 
interface with a single function that returns the value to be used. 
That's a bit more boilerplate than I would like.

In Erlang, however, there is no reason to limit the type of a module 
parameter. Indeed, the only way to enforce it would be to add runtime 
checks at each entry point. The implementation is not simplified - it 
gets more complicated. In practice, it is probably a good idea to mostly 
parameterize modules with respect to other modules (i.e., callbacks), 
but there's no point in trying to enforce that.

     /Richard