[Haskell] URLs in haskell module namespace

Mon Mar 21 22:06:25 EST 2005

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 <pesco at gmx.de> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>