[Haskell] URLs in haskell module namespace

[S. Alexander Jacobson]

A few quick thoughts:

1 Although technically HTTP URLs are locations rather than 
identifiers, that is the behavior we want in this context.  If you 
want to trust someone else to serve you the correct module, you should 
specify it. A formal spec should define exactly what URI schemes are 
supported.  I would like support for HTTP and HTTPS.

2. Versioning is an issue independent of whether Haskell allows 
HTTP URLs as module locators.  However if Haskell does end up with 
versioning AND HTTP support, it might make sense for it to use WebDAV 
versioning to access remote modules.

3. I love the concept of adapters.  In particular, I'd really like a 
way to make sure that Prelude.read does not produce an error when the 
saved representation of a datatype differs from the current one. 
Manual management is a big PITA. (And yes, this too is orthogonal from 
the question of URLs in haskell module namespace.)

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com





On Mon, 21 Mar 2005, Sven Moritz Hallberg 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
>
> 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
>