[Haskell] URLs in haskell module namespace
lemmih at gmail.com
Mon Mar 21 20:25:50 EST 2005
On Mon, 21 Mar 2005 23:06:25 +0100, Sven Moritz Hallberg <pesco at gmx.de> wrote:
> Greetings Alexander,
> I have been thinking about something very much similar for some time.
> Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson:
> > As I move from machine to machine, it would be nice not to have to
> > install all the libraries I use over and over again. I'd like to be
> > able to do something like this:
> > import http://module.org/someLib as someLib
The extra complexity outstrips the gain since installing a package
will soon be as easy as this: 'cabal-get install myPackage'. Checkout
the Cabal/Hackage project.
> I'm not sure a URL is the right thing to use. For instance, what about
> the http part? In the end, the URL gives a certain location for the
> module, which might change. Programs using the module should not become
> invalid just by movement of the dependency.
> > If the requested module itself does local imports, the implementation
> > would first try to resolve the names on the client machine and
> > otherwise make requests along remote relative paths.
> > If would be nice if implementations cached these http requests and did
> > If-Modified-Since requests on each compile. If the document at the
> > URL has been modified it might show the diff and ask the user if it is
> > appropriate to upgrade to the new version.
> Exactly. I think, even, that this kind of handling is what we _need_. I
> routinely feel, in writing my own modules, the hassle of questions like
> "how do I package this?". It would be much easier and accessible to
> just put my modules up one by one on the Web, advertise them (by
> posting the documentation, preferably ;)) and know that people's GHC or
> whatnot will just auto-fetch them.
This is exactly what Cabal and Hackage is solving.
> The next thought of course is versioning. To make sure my Haskell
> system gets the version I meant when I wrote my program, modules need
> version numbers. I'd propose the following.
> module A [1,5.2] (...) where ...
> The bracketed expression after the module name is an interval of
> interface numbers: This version of the module exports interface 5.2,
> the decimal indicating the second revision since no. 5. The module
> further declares to be backwards-compatible with all interfaces down to
> version 1, inclusively (i.e. they form a sequence of subsets). Nota
> bene this scheme is the same as that used by GNU libtool (although
> libtool explains it much too complicated).
> A module author would start with interface 1 (i.e. write [1,1]) and
> upon changing the module:
> - If the change was only a code revision with no interface or semantic
> changes at all, raise the fractional part, e.g. [1,1.1]
> - If there was any change in the module exports, or the semantics of
> existing exports, raise the interface number (upper bound) to the next
> integer, e.g. [1,2]
> - If the change broke compatibility with the last version (i.e.
> removed or changed any of the existing exports), snap the lower bound
> up to reduce the interval to a single element again, e.g. [3,3].
> import A 2 (...)
> The import statement includes a single integer interface number which
> is the number of the interface this module was written against. It
> indicates that any version of module A whose interface interval
> contains 2 is compatible.
Cabal is using package based versioning and you can show/hide packages.
> Obviously, the Haskell system should be able to provide some
> convenience for managing the interface numbers. It should also be
> possible to devise a smart way of handling omitted interface info (both
> on the ex- and import side).
> Finally, one will wish for a system of providing adaptor modules to
> interface old importers to new versions of their importees. That way,
> interfaces can be evolved rapidly because backwards-compatibility need
> not be retained, as long as one provides a suitable adaptor (to be
> auto-installed by an importing system). In such a setting, the simple
> "latest compatible interval" approach also becomes sufficient to handle
> even strong interface fluctuation because gaps can always be bridged
> with adaptors.
You don't need a new package system for this.
> Does this make sense?
I understand your desire but all of this can/will be handled by Cabal
More information about the Haskell