On Tue, Apr 12, 2005 at 02:57:48PM -0400, S. Alexander Jacobson wrote:
My main goal here is to free the user from the hassle of manual package installation. A module written in one location should "just work" when moved to another. Right now, we have that location transparency within a single box or networked file system. I am saying we should also have it for moves accross the Internet.
So, the meaning of an import statements should not depend on its context (in effect, module identifiers in import statements should be a form of URL) and compilers/interpreters should be able to resolve those URLs to module implementations without user intervention.
And, if the meaning of module names is parametrized by package then package names should be part of import statements. If packages are purely adminisistrative, then they shouldn't.
Do we agree on at least this much?
What you describe sounds to me like a nightmare. It means I'd have to have a different import statement (protected by #ifdefs) for every version of each module I want to support--since in practice every version will change the interface. If all users are always connected to the internet, and all packages work with every version of every compiler, then yes, having a global namespace for modules where every interface change results in a module name change sounds great. But in a world where some users use older compilers, and some users aren't always connected to the internet, one would like to be able to change module interfaces without having to change all code that uses that module. -- David Roundy