Why do we need modules at all?

Summary

Hello Joe,I've personally wanted an easy way to load modules from different places.If you started with making modules easy to load from different places, then later provide support for functions, I imagine this would be easier to implement immediately and easier for people to make use of immediately ... where "people" refers to me :)I've got two suggestions (mostly inspired by the Mozilla Framework)...1. How about letting the programmer choose where the functions come from (kv store, fs, web-server, etc)...For instance, a module could start...-import(["file://misc/collect_int", "http://erlang.org/lists/*", "mnesia://db1/misc/merge_kv"]).By default, the code loader would know what to do when it encounters "file://", "http://", "https://", "ftp://", "sftp://" and "mnesia://" URI schemes. Programmers could be allowed define their own URI schemes by providing callbacks for loading code. For instance, one would be able to define "ubf://" and have the code loader call his/her code when it encounters "ubf://foo/bar"2. Expanding on this: letting the programmer centralise the possible locations of modules/functions and use this to define namespaces...One possible way of doing this is to steal from the "chrome registration" system that the Mozilla Framework uses. A programmer could define one-level deep namespaces in a configuration file which points to targets that could come from anywhere, then use that in her modules. A module could then start...-import(["erlang://misc/collect_int", "erlang://couch/mapreduce"]).Where "misc" and "couch" are namespaces and "erlang://" is a special URI scheme telling the code loader to refer to the configuration file "erlang.manifest" which would contain...[{"misc", "file://./ebin/misc.beam"}, {"couch", "http://localhost:7777/ebin/"}]Where "couch" points to a yaws server serving couch beams, or something along those lines. Then she can easy switch between different code sources using one file.A code-signing system could also be introduced.- E...