Some questions to consider before a module system is implemented:
1. Why?
I can see two different use cases for modules: a) controlled sharing and reuse; b) one more tool to encapsulate functionality inside the program. Which one is it, or is it both? Neither?
2. Should modules (module names) map directly to the file system hierarchy?
Why should they? Aren't they a different concept? Would it be reasonable to have more than one module per file, or more than one file per module? And what would happen when I wanted to move files?
Why shouldn't they? Aren't they ultimately saved in files?
3. Do we really need multiple namespaces?
Only a single namespace? Consider this: let the file or module where execution started from be the namespace. Let each imported/loaded module have an anonymous, uniq'd namespace from which symbols are imported. Repeat recursively, and you only get conflicts if you explicitly import two same symbols in a module.
1. Reuse. Encapsulation is largely unnecessary, given with and withs (although I think we need withrec).
2. no:no:no:no:no:no:no
3. What you described is still multiple namespaces, even though we are just "working" on a single one - and besides, who says we'll be working on a single namespace when the Arc Server can serve several applications?
