[Haskell] URLs in haskell module namespace

Lemmih lemmih at gmail.com
Tue Mar 22 08:03:08 EST 2005

On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S.
Alexander Jacobson <alex at alexjacobson.com> wrote:
> Proposal restatement:
> 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
> Advantages:
> * 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
> retrieve/build/install cycle.
> * 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
> vanishes.
> 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?

Hackage and (the soon to come) cabal-get are tools layered on the
Cabal but they are not a part of it.
Hard coded URLs are evil in almost every context, IMHO. But defaulting
to some server when the user hasn't specified otherwise would greatly
increase the ease of use.

> 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).

The idea with Hackage was to create a central place for people to put
software or links to software, so keeping only one server for free (as
in beer) packages would be desirable. However, this does in no way
limit how Hackage can be used for private code repositories.

> 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.

Specifying sources on the cmd line or in /etc/cabal/sources.list
sounds more maintainable to me.

> >> 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
> > functionality?
> 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
> Text.XML.Parse.
> 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
> problem.

But they are! GHC can even handle several versions of the same
package. Modules from a package wont be in scope if you hide or ignore

> -Alex-
> ______________________________________________________________
> S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com


More information about the Haskell mailing list