dumb cabal question

Frederik Eaton frederik at a5.repetae.net
Sun Sep 4 17:15:12 EDT 2005

By the way, as I've been thinking about Cabal, I remembered this
question to which I haven't found an answer. I realize that I haven't
been party to the initial discussions, but John Meacham didn't know
the answer either, so I will ask it.

As I understand it, Cabal is meant to provide people with a
compiler-independent way to build Haskell packages. So it (a) builds
packages while (b) abstracting over compiler interfaces. Why was the
decision made to couple these two functions into a single project? It
seems to me that maybe having two separate projects would be more
manageable and useful.

- The first project would provide a standard command-line interface to
Haskell compilers. There would be operations such as: compile a file
into an object file (may be a no-op); link a bunch of object files
into a package; install a package into the following package database;
create an empty package database; merge two package databases; find
dependencies of a module. And options like: use the following other
packages, search for packages in the following package database.
Basically, the things that compilers can do, but given a standard

- The second project would provide a build system. I guess there would
be a lot of options here. There seems to be a demand for a system with
some main declarative specification file which can be processed by
external tools to find out what dependencies a project has on other
projects, etc., which Cabal is responding to. So perhaps people would
write something like this. However, if there were two separate
projects, then developers would also have the freedom to use a build
system like 'make', or something more sophisticated and unforeseen,
with the generic compiler interface as well.

By decoupling the standard compiler interface and the build system,
one would be able to make improvements independently to each one.
Design and development would be faster, users would have more choices,
it would be easier to experiment with new versions of each project.

So, back to my question. Why couple the two?



More information about the Libraries mailing list