[Haskell] URLs in haskell module namespace

[S. Alexander Jacobson]

On Tue, 22 Mar 2005, Malcolm Wallace wrote:
>> 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.

Ok, well lets unpack what is actually required here:

1. Change of syntax in import statements
GHC already has lots of new syntax.

2. Module names with package scope
GHC already has a -i.  I assume the complexity of generating a -i 
w/r/t a notation provided in the import statment is not that high.

3. Networking Client
I think GHC already bundles Cabal and Cabal already handles being a 
network client and doing some database mapping.  (Lemmih: Please 
correct me if I am mistaken).  Also, it is ridiculous for a modern 
language implementation NOT to have a network client library.

4. Caching
Caching is new, but it is not that difficult to add to an extisting 
HTTP requester and the benefits seem well worth this marginal cost.

5. Maturation of Packaging Tools
I agree that the packaging tools are immature.  That is why it makes 
sense to evaluate this proposal now.  No one has a big investment in 
the current packaging model and packaging tools optimized for a 
language that works in the way I propose would look very different 
from packaging tools organized for the pre-Internet world.

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

Disaster?  I don't think so.  That is why purl.org exists.  The HTTP 
302 status code is your friend.  If you don't want to use purl.org, 
feel free to set up your own redirect server.  I imagine various 
different redirect servers operated by different people with different 
policies about what counts as a bug fix vs what counts as a new 
version, etc.

And btw, it is a failure of Haskell right now that imports don't 
create dependency.  Right now, I would like a sane way to import two 
different versions of the same module so I can do file conversion.  It 
seems like the only way to accomplish this in Haskell as it stands 
is to rename one version and then I'm back in the world of global 
search and replace on import lines again.  It would be MUCH 
niceer do this via packages URLs instead.

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

How do I depend on multiple versions of the same package in a single 
module?  How do I make sure that my .cabal file is up to date with the 
actual content of my imports?  I am proposing to automate this 
process.  You appear to want to keep it manual.

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

See my comment to Lemmih about the possibility of multiple hackage 
servers and needing to know locations on each of those servers.

If Haskell allowed import of package URLs then a hackage server would 
just be one of many 302 servers (like Purl.org) and not require 
special plumbing.  Note, you different people might have different 
judgements about what constistutes a bugfix vs a new version.  You 
can't rely on the package author to agree with you!

-Alex-

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