On Mon, 21 Mar 2005 23:06:25 +0100, Sven Moritz Hallberg <[EMAIL PROTECTED]> wrote: > Greetings Alexander, > > I have been thinking about something very much similar for some time. > But: > > 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 and Hackage. -- Friendly, Lemmih _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
