[Haskell] URLs in haskell module namespace
S. Alexander Jacobson
alex at alexjacobson.com
Tue Mar 22 18:30:46 EST 2005
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.
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.
>> * 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
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!
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Haskell