dumb cabal question

[Frederik Eaton]

To clarify: Maybe I should have pointed out more explicitly in this
message that I *do* understand that Hugs is an interpreter, and
doesn't produce object files, or compiled packages. I understand how
Cabal works with GHC and Hugs. My question, why a build system is
needed to abstract away their differences, has yet to be addressed. It
could be that the answer is simply that it was thought that the
current way of doing things would just be more convenient, but in any
case I think the question should be addressed and not evaded.

A build system is something that manages dependencies between and
schedules the execution of commands. I see no reason why all Haskell
compilers and interpreters could not be given an standard interface
which (1) provides a way to find dependencies of sources (2) provides
a way to execute all the necessary commands supported by Cabal, so
that any build system could be used with any compiler to build any
Haskell code, and do what Cabal does now.

Furthermore, I would like to point out that this issue may have much
greater importance in Haskell than in other languages, due to the fact
that it is hard to imagine a standard Haskell ABI. In C, one can
compile ELF libraries with different compilers (I think) and still use
them in the same application - this is the layer where the
standardization exists. Haskell, on the other hand, needs to have
library and executable compiled with the same compiler, or interpreted
with the same interpreter. It is good of the Cabal people to recognize
this need and address it, but I'm inclined to think that a
light-weight compiler interface would be more appropriate as a
standard, than one which is tightly coupled with a build system. Note
that I'm not suggesting Cabal be abandoned - it would be possible to
develop a compiler interface standard, and modify Cabal to use it.
Cabal would become much simpler; conforming to the standard would
become the task of individual compiler developers.

Frederik

On Sun, Sep 04, 2005 at 02:15:12PM -0700, Frederik Eaton wrote:
> 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
> interface.
> 
> - 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?
> 
> Frederik
> 
> -- 
> http://ofb.net/~frederik/
> 

-- 
http://ofb.net/~frederik/