Why is there a cabal file at all?

[Simon Marlow]

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
    of packages.

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 
even murkier.

Cheers,
	Simon