[Haskell] URLs in haskell module namespace

[Sven Moritz Hallberg]

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

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.

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.

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.


Does this make sense?

Cheers,
Sven Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
Url : http://www.haskell.org//pipermail/haskell/attachments/20050321/2cfd3339/PGP.bin