Why is there a cabal file at all?
simonmar at microsoft.com
Mon Jan 15 11:21:05 EST 2007
Conal Elliott wrote:
> On 1/12/07, Isaac Jones <ijones at syntaxpolice.org
> <mailto:ijones at syntaxpolice.org>> wrote:
> These tools would have to be Haskell interpreters if they wanted to
> read a .hs file and derive the package description from that.
> Thanks, Isaac. This statement helps me a lot. Now I think you really do
> mean "code" in the literal sense (the second one I suggested), as in
> Haskell code ( "the content of a .hs file"). (I've often heard people
> say "code" or "expressions" when they mean the denotations of such
> things, especially in regard to lazy languages.)
> What I'm talking about is that if you have a programatic way of
> producing the package description, then you no longer have a way of
> "reading" that package description from another tool.
> Maybe I'm missing something, but I think I see a simple way to do just
> that. The "programatic way of producing" is the Haskell code, and "the
> package description" is the data. That data might be higher-order, with
> no textual description other than the original source code. Another tool
> "reads" in that description by being passed the data. Maybe that means
> running the code (e.g., loaded dynamically) or unpickling a persisted
> version, or simply by being in a function composition chain.
So there are two issues, one of which has been pointed out already:
- trust: Hackage doesn't want to run arbitrary code to extract a
package description, for example. It could, by using a sandbox of
some variety, but that's a lot of effort to go to just to extract
the package metadata.
- tools that not only read, but write the package metadata. For
example, in Visual Haskell you can load up an existing package in
the environment, add a few modules, and save it again as a valid
Cabal package. Sure we can only do this as long as you don't
use Setup.lhs for anything non-trivial, but that's a large class
As Isaac already said, the original design was code-only. It was due to the
Visual Haskell requirements that we decided to move to a mixture of code & data.
Finding the right place to put the boundary has been tricky, and is
necessarily a compromise: we want to support as many packages as possible with
just .cabal, and yet not complicate the language (and its implementation) too
much. Now that we're getting into conditionals and suchlike, things are getting
More information about the cabal-devel