Why do we need modules at all? by Joe Armstrong http://erlang.org/pipermail/erlang-questions/2011-May/058768.html

(Re-Posting from DM with @Mariano Guerra ) I've been thinking about something similar some time ago and would love to see it implemented somewhere. One problem I see with "globally unique function names" though is that everyone would have to agree on how to name things. This will lead to very weird function names eventually because "intuitive" names are already taken. A possible solution to this problem would be to use content-hashs instead of names in the key-value-store. An environment could allow users to define alias names for hash values so that one could view / edit code using intuitive names. Behind the scenes, the environment would write the hashs to source files. This would push human-readable names to the presentation layer (which could be customized by users) and would also make name-resolution trivial. Functions could have a "default name" that wouldn't have to be globally unique. An environment could use this default name to decide how to display functions for which there's no alias defined. If the default name equals an alias, it could automatically be displayed differently (e.g. using different color or by adding

*

to the displayed name). A problem with this would be that different people could use different names for the same function which would make talking about it difficult (just imagine viewing a presentation of a team member who uses different alias names for every function). This problem could be addressed by sharing alias sets or even having recommended alias sets maintained by organizations. Because aliases could be changed without breaking any code, alias sets could evolve more quickly which would hopefully let them converge to a universally agreed upon alias set. Individual users could still tweak these sets if they feel they need to.

I strongly agree with Joe's perspective on modules. They're ultimately an arbitrary construct, and conflate several different goals (most of which relate to working with text files and avoiding name clashes). The only true utility they offer (as far as I see) is the ability to define abstract data types whose implementation is hidden. For such a use case, we could use a simpler construct, something akin to a standard

let

expression (see Haskell/ML) that returns names to add to a scope (rather than a value).