[erlang-questions] Why do we need modules at all?

[jm]

On 24/05/11 9:25 PM, Joe Armstrong wrote:
>
> If we think of modules as containers of functions, then a module is a 
> "set of functions" -
> my problem is with granularity. The smallest unit of reuse is the 
> module. Suppose my application
> want just one function from a particular module - I'm forced to load 
> the entire module.
>
> This hampers reuse - I *often* read library code and find a single 
> function and cut-and-paste it into
> my new code. It also discourages sharing - since the smallest unit I 
> can share is a module.
>
> The unit of distribution is an application - a set of modules - why 
> this could not be a list of functions
> I do not know.
>
> I think I'd like to view an application as something that offered a 
> message based service that internally
> was constructed from a set of functions rather than a set of modules.
>

Here's a "mad hatter" suggestion. Introduce the concept of a "shadow" 
module. For example, say your using the list module and your after a 
lists:randomise/1. In this proposal you'd have your own lists module, 
say joes_lists,

-module(joes_lists)

randomise(List) ->
   %% code to randomise the order of the list


In you code you would then say,

-shadows(joes_lists, lists).

then use lists:randomise(AList) in your code. The compiler would first 
check the lists module and if the required function didn't exist it 
would use your modules. This would avoid you accidentially overriding 
the main modules definitions which may cause confusion. In such a case, 
the clash should be treated as a compilation error.

The second part would be distribution and release management. There's 
several ways this could be done one would be to have a script which 
would build a set of "patch modules" which would be the cut down 
versions of your own development modules containing only the code and 
associated documentation your using in the current project.

Actually, it might be better to include this as part of the project 
development: execute a script which scans your code repository and the 
-shadow/2 compiler directives and generates the shadow modules as 
needed. This could mean that your custom modules could be kept in a git 
or mercurial repository, on a web server, or in a key-value store. The 
URLs would then be part of the configuration for this script along with 
version tags, etc. Yes, I going to ignore how the modules get in there 
in the first place.

Jeff.