<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> On 1/12/07, Isaac Jones <<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org
</a>> wrote:</blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> These tools would have to be Haskell interpreters if they
wanted to read a .hs file and derive the package description from that.<br></blockquote><br>Thanks, Isaac. This statement helps me a lot. Now I think you really do mean <span>"</span>code<span>"</span> in the literal sense (the second one I suggested), as in Haskell code (
<span>"</span>the content of a .hs file<span>"</span>). (I've often heard people say <span>"</span>code<span>"</span> or <span>"</span>expressions<span>"</span> when they mean the denotations of such things, especially in regard to lazy languages.)
<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
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 <span>"</span>reading<span>"</span> that package description from another tool.<br></blockquote><br>Maybe I'm missing something, but I think I see a simple way to do just that. The
<span>"</span>programatic way of producing<span>"</span> is the Haskell code, and <span>"</span>the package description<span>"</span> is the data. That data might be higher-order, with no textual description other than the original source code. Another tool
<span>"</span>reads<span>"</span>
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.<br><br>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.<br><br>Cheers, - Conal<br><br>P.S. True Confession: I enjoy makefile hacking, in a guilty pleasure sort of way.<br><br><div><span class="gmail_quote">On 1/12/07, <b class="gmail_sendername">
Isaac Jones</b> <<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"Conal Elliott" <<a href="mailto:conal@conal.net">conal@conal.net</a>> writes:<br><br>> On 1/10/07, Isaac Jones <<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org</a>> wrote:<br>>
<br>>> ...<br>>> Remember: Cabal isn't only the build infrastructure, it's also the<br>>> metadata format that tools like Hackage use. If you decide to combine data<br>>> and code, you will no longer be able to manipulate the data with another
<br>>> tool.<br>>><br>><br>> I'm worried and confused about this conclusion. I want to address my<br>> confusion first, and maybe the worry will be handled.<br>><br>> By "data" vs "code", I'm guessing you mean simple first-order values, and
<br>> mainly strings, vs everything else (especially functions). But I wonder if<br>> instead you mean any Haskell value (including functions) vs the content of a<br>> .hs file?<br><br>I'm not sure what you mean here. What I'm talking about is that if
<br>you have a programatic way of producing the package description, then<br>you no longer have a way of "reading" that package description from<br>another tool.<br><br>> Maybe I'd have a firmer grasp of this issue if I could had in mind an
<br>> example of such a metadata-manipulating tool. Would someone please suggest<br>> one?<br><br>Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools<br>that read the .cabal file and perform operations based on the package
<br>metadata. These tools would have to be Haskell interpreters if they<br>wanted to read a .hs file and derive the package description from<br>that.<br><br>peace,<br><br> isaac<br></blockquote></div><br>