[Haskell] URLs in haskell module namespace
S. Alexander Jacobson
alex at alexjacobson.com
Tue Mar 22 06:40:02 EST 2005
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements allow us to import two different versions of Network.HTTP
import http://domain.org/package-1.0.cabal#Network.HTTP as HTTP
import http://hage.org/package-2.1.cabal#Network.HTTP as HTTP2
--note use of HTTP fragment identifier for module name
* Simplified place for user to track/enforce external dependencies.
If you are using non-standard modules, you had better know where they
came from and how to get another copy. This proposal provides a sane
way to do that (see below).
* It makes it easy to move code between machines.
The implementation takes care of retreiving and building the packages
automatically and as necessary. There is no need for a separate
* Eliminates the horrible globality of Haskell's module namespace
You can use two modules with the same name and different functionality
and you can use two modules that use different versions of the same
module. (see below).
* Users no longer need to think about package installation scope.
Package installation is with respect to the current use. Whether
multiple users are able to share the same installation is up to the
installation. User's can't infest the machine's local namespace by
adding new packages.
On Tue, 22 Mar 2005, Lemmih wrote:
>> 1. knowing the source package for each module used in their code
>> even if they didn't insall the packages in the first place i.e.
>> import Foo.Bar just worked on my development machine.
> I'm not sure I completely understand what you're saying but knowing
> the exact URL for every single module import seems more of a hassle
> than installing a few packages. You could perhaps even make a shell
> script containing 'cabal-get install package1 package2 ...'.
I am assuming that I may want to move my code to another machine and
that therefore I need to keep a record *somewhere* of the source
package of every module I actually use. If I don't, then moving will
be much more difficult. Yes, keeping track of these packages is a
hassle, but I don't see how it can be avoided.
Once I am keeping track, the *somewhere* that it makes the most sense
to me to do so is the point in the code where I am importing the
module. That way the implementation can enforce correspondence and if
I stop using the module, the package dependency automatically
Doing this sort of work in a separate script strikes me as a
maintenance headache and means that all modules I use have to coexist
in a shared namespace which seems likely to create more headache.
>> 2. knowing the current location of those packages even if they
>> didn't obtain them for installation on the original machine
>> where they used them and aren't on the mailing list for them.
> I assume you meant something like "The developer don't know where to
> find the packages".
> The location of the packages is irrelevant to the developer since it's
> handled by Cabal/Hackage.
I don't understand. Are you saying that there will be only one
Hackage server ever and it will have all information about all
packages everywhere and that the location of this hackage server will
be hard coded into every cabal implementation?
If so, I find that vision incredibly unappealing. I believe there
should/will be multiple hackage servers with carrying different
hackages under control of different parties (e.g. a corporation might
have one for its own private code).
And, if there are multiple hackage servers, we are going to need to
indentify the server from which a particular package originates and
the location of that package on that server. This proposal provides
an obvious method of doing so.
>> And a big bonus here is we get a simple solution to the problem of
>> Haskell's global module namespace.
> There was a problem with module name spaces? Wouldn't there only be a
> problem if two packages used the same module name for different
Yes, and that happens whenever you have different modules using
different versions of the same module and it also happens when two
different authors both chose to name their libraries Network.HTTP or
If module names were with respect to packages that would be entirely
fine. But right now module names are global and that is a serious
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Haskell