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 _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
