[erlang-questions] Parameterized module idioms

[Paulo SŽergio Almeida]

Hi,

Vlad Dumitrescu wrote:

> * Of course it's easier to use module parameters instead of passing
> closures or state around. Just like it's easier to use global
> variables instead of function arguments. That is, as long as you can
> remember them all and until something breaks because of a change in a
> seemingly unrelated module... There's a reason some people like the
> functional style better.

Some of the nice things in functional style are absence of side effects 
and referential transparency. Updating global vars may be a problem, but 
we are not talking about that. Using parameterized modules will not make 
us have global (mutable) variables or side effects (more than we already 
have in the language, which is not purely functional), neither will we 
loose referential transparency. This has nothing to do with loosing 
functional style.

I am not talking about emulating objects and programming with a 
different style; I see an important use of parameterized modules to 
avoid having to thread all over things that for all practical purposes 
are "constants".

People say the difference between:

E:f(...)

and

m:f(..., E)

is not much and so whats the fuss. Its not this difference that may be 
significant, but to have to propagate, split, and reconstruct the 
components that make up E until they reach this point in the program, 
meanwhile polluting and obfuscating "innocent" functions in the 
invocation chain.

> * Personally, I don't think it's a good idea to try to graft features
> on a language, for which it wasn't designed from the start. Most of
> the time the result is an ugly hybrid. It feels a lot better to
> implement different languages targeting the platform, each matching a
> different style.

 From this reasoning we would not have funs as they did not exist from 
the start. But anyway, parameterized modules are pretty orthogonal to 
the main features of the language.

> * Parametrized modules aren't the same thing as modules as a data
> type. At the moment, they are basically syntax sugar and there are

Why not? I can already pass them around and store them in data 
structures, like I do for closures; what remains to be added is proper 
support so that modules are a new runtime type and I can do type 
testing, e.g. is_module/1 and so on.

> some weird effects (bugs!) because of that:
>       > {lists,hello,world}:reverse([1,2,3]).
>       [3,2,1|{lists,hello,world}]
> The (higher-level) reason for this bug is just that there is no module
> data type to query if it is parametrized or not.

This is not a problem with the concept itself but with the (lack) of a 
proper implementation. Some strange things could also happen before 
proper support for funs was added.

I don´t know what the plans are, but yes, it would be nice to have them 
properly supported and not as the hack they are now.

Regards,
Paulo