Lemmih,
The current Haskell/Cabal module and packaging system is substantially annoying for the typical non-sysadmin end-user. In particular, if they move their code to another machine they have to do a bunch of different administrivia including:
1. knowing the source package for each module used in their code
even if they didn't insall the packages in the first place i.e.
import Foo.Bar just worked on my development machine. 2. knowing the current location of those packages even if they
didn't obtain them for installation on the original machine
where they used them and aren't on the mailing list for them. 3. going through the hassle of doing a "cabal-get install" for each
of them once they have figured it all out.I'd rather have a system that takes care of 1-3 for me and just reports errors if particular modules are irretrievable.
That being said, Cabal definitely solves a lot of problems that my original proposal left unaddressed (e.g. producing executables needed to build modules, handling C code, versioning?). Perhaps the correct answer is to import Cabal packages rather than haskell source e.g.
import http://package.org/package-1.0.cabal#Foo.Bar as Baz import http://package.org/package-2.0.cabal#Foo.Bar as Baz2 --note use of HTTP fragment identifier for module name
And a big bonus here is we get a simple solution to the problem of Haskell's global module namespace. Now module namespace is local to individual packages.
If cabal also has a "cabal-put package MyPackage http://myhost.com/dir"; then we have a really simple and beautiful system for sharing libraries over the Internet as well!
If the change of import syntax is blessed by the powers that be, would it be hard to adapt Cabal to work like this?
-Alex-
______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Tue, 22 Mar 2005, Lemmih wrote:
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
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
