Re: Why is there a cabal file at all?

Conal Elliott wrote:

On 1/12/07, Isaac Jones mailto:ijones@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