[Haskell] URLs in haskell module namespace
Sven Moritz Hallberg
pesco at gmx.de
Mon Mar 21 17:06:25 EST 2005
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
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
Does this make sense?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: Signierter Teil der Nachricht
Url : http://www.haskell.org//pipermail/haskell/attachments/20050321/2cfd3339/PGP.bin
More information about the Haskell