[Haskell] URLs in haskell module namespace

[S. Alexander Jacobson]

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?

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

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