Ideas for library infrastructure

Andres Loeh
Fri, 25 Apr 2003 11:11:50 +0200

This is an attempt to summarize and separate the problems, in
the way I see them:

There are two things that are too complicated right now:

[1] A library writer needs clear instructions what he can do with
    his library to package it in a standardized way usable with
    as many Haskell systems as possible.

[2] A library user needs a normalized way to install additional
    libraries into his Haskell system(s) and keep them up-to-date.

The following factors make both problems hard to solve:

[A] There are multiple Haskell "compilers" out there, with very
    different properties. They support a different number of
    extensions, have different command line flags, one isn't even
    a compiler ;-) Furthemore, they have their own package systems
    which are incompatible.

[B] Different versions of the same compiler are binary-incompatible.
    So on a compiler upgrade, the user will either need to reinstall
    libraries completely or at least do something to recompile the

The current approach, as mentioned before, is to make the set
of standard libraries increasingly large. I agree that this is
not a really good solution, because compile times increase, the
users may get huge sets of libraries they don't really need, and
they may get them multiple times. A project that works that way,
for example, is KDE. It is quite hard to upgrade single packages
without upgrading the entire Desktop environment plus libraries.
There, I don't find that situation ideal, and still, KDE is at
least centrally organized and has global releases. The Haskell
compilers are all separate and should stay that way.

The situation as it is almost completely rules out binary-only 
versions of libraries. I will thus try to focus on source based
libraries from now on.

I vote for a two-level approach:


Define a clear and precise way how and where a Haskell library
has to be installed on a system. This installation should be
as compiler-independent as possible. The files should go in a
central place, and there should be additional information at
that location of the kind that is now for example stored in GHC's 
package configuration file.

As far as a library does not depend on a particular Haskell compiler 
(for example, it needs C libraries as well), these C libraries may
well aready be built and installed. But the Haskell code should
be installed in source form. 

Authors of libraries should find these guidlines in a clear and
easy to understand form somewhere on the web, and there should be
tool support to facilitate conforming to the standard. I'd go for
some well-documented Makefile includes, but if nicely written, a
Haskell based system may also work. But I think, the system and language 
here is secondary, as long as it is clear _what_ needs to be done ...


Each Haskell compiler should be extended with a tool that can
take a library from the standardized source based install described
in I. This tool could be similar in interface to ghc-pkg, but should
not only collect package configuration information, but also _build_
the Haskell code for the compiler and create and install libraries to
the right positions as necessary. The tool should provide a way to
_add_, to _remove_, and to _completely regenerate_ libraries. 

Additionaly, there needs to be one single tool, that levels the potential 
differences between the package tools of the Haskell compilers and keeps 
track of all the compilers installed in a system. Let's call it 
"global package manager".

The last thing that would be called in the Makefile (or whatever)
that is supplied with a library is the global package manager with the 
option "add" and the library name. The global package manager would look 
in the standardized central place for the library, find out for which of 
the installed Haskell compilers it works, and call their respective 
package managers that will the build and add the library individually.

The last thing that would be called in the Makefile (or whatever)
of a Haskell compiler would be its own package manager with the option to 
regenerate all libraries. Because they are installed in a place 
independent of the compiler itself, they will survive a compiler upgrade 
and can automatically be rebuilt for the new version. For hugs rebuilding 
would be nearly trivial, for GHC is might take a long time, but that's 

Summary of the proposal:

* Define a clear standard to install Haskell libraries on a system in a 
way that is independent of a specific Haskell compiler (both type and 

* Support library writers by tools to make sure they can conform easily
to that standard. This includes a global package manager that can be 
called in the end to pass responsibility over the library to the compilers 
installed on the system.

* For each Haskell compiler, write a/modify the package manager so that it
can handle the addition, removal, and complete regeneration of such 
source-based installed libraries.

This will make the situation easier for package writers, because they do 
not have to care about actually _building_ the library for a specific 
compiler or compiler version. They will only have to conform to a specific 
installation format, and that will be supported by tools.

This makes life easier for the users, because they can just install 
additional libraries and "never" have to worry about them again. If they 
install additional Haskell compilers or upgrade to newer compiler 
versions, the libraries will always automatically become available.

Of course I realize that I probably have forgotten many things and that I 
may not have made myself clear at all points. So you're all invited to 
tear this proposal apart!



Andres Loeh, Universiteit Utrecht