[Haskell] URLs in haskell module namespace

Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk
Tue Mar 22 07:14:38 EST 2005

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

> 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

I cannot see any of the Haskell compilers ever implementing this idea
as presented.  It would introduce an enormous raft of requirements
(networking client, database mapping, caching, etc) that do not belong
in a compiler - they belong in separate (preprocessing/packaging)
tools.  Furthermore, these tools already exist, albeit they are young
and have a long maturation process still ahead of them.

> Advantages:
> * Simplified place for user to track/enforce external dependencies.

No, it spreads the dependency problem over lots of import statements,
which will quickly become a maintenance headache when the URLs
become invalid.  Imagine a GUI project that uses, say, the GTK+
libraries in a hundred different import statements.  Then the GTK
server moves to a different URL.  Disaster!

It would be much better to group the dependencies into a single
file per project - so there is just one place where changes need to
be made.  This possibility already exists - just create a .cabal file
for the project.

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

The Hackage project is exactly a database of package/location mappings,
which the /author/ of each package can keep up-to-date, not the user.
Much more maintainable.


More information about the Haskell mailing list