Why is there a cabal file at all?

[Conal Elliott]

>
> On 1/12/07, Isaac Jones <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.

I'm loving my experience with Cabal so far, and I'm grateful to you and
others for creating and evolving it. I'll keep using it, even if it's not
painted my favorite color. And I can't help but notice that I have to repeat
myself (across Cabal files) and later go back and change all of my Cabal
(and make) files when I better understand the tool and my own needs. And in
spite of saying more than I want to in a Cabal file (repetition), I still
can't say all I want to say, so I resort to makefiles. In Pavlovian style, I
can't help wondering if a lovely little Haskell EDSL might give me more
succinctness, more flexibility, and freedom from those crufty old makefiles.

Cheers, - Conal

P.S. True Confession: I enjoy makefile hacking, in a guilty pleasure sort of
way.

On 1/12/07, Isaac Jones <ijones at syntaxpolice.org> wrote:
>
> "Conal Elliott" <conal at conal.net> writes:
>
> > On 1/10/07, Isaac Jones <ijones at syntaxpolice.org> wrote:
> >
> >> ...
> >> Remember: Cabal isn't only the build infrastructure, it's also the
> >> metadata format that tools like Hackage use. If you decide to combine
> data
> >> and code, you will no longer be able to manipulate the data with
> another
> >> tool.
> >>
> >
> > I'm worried and confused about this conclusion. I want to address my
> > confusion first, and maybe the worry will be handled.
> >
> > By "data" vs "code", I'm guessing you mean simple first-order values,
> and
> > mainly strings, vs everything else (especially functions). But I wonder
> if
> > instead you mean any Haskell value (including functions) vs the content
> of a
> > .hs file?
>
> I'm not sure what you mean here.  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'd have a firmer grasp of this issue if I could had in mind an
> > example of such a metadata-manipulating tool. Would someone please
> suggest
> > one?
>
> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
> that read the .cabal file and perform operations based on the package
> metadata.  These tools would have to be Haskell interpreters if they
> wanted to read a .hs file and derive the package description from
> that.
>
> peace,
>
>   isaac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070113/69107dab/attachment.htm