<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 &lt;<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org
</a>&gt; 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&#39;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&#39;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&#39;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&#39;m loving
my experience with Cabal so far, and I&#39;m grateful to you and others for
creating and evolving it. I&#39;ll keep using it, even if it&#39;s not painted
my favorite color. And I can&#39;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&#39;t say all I want to say, so I resort to
makefiles. In Pavlovian style, I can&#39;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> &lt;<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&quot;Conal Elliott&quot; &lt;<a href="mailto:conal@conal.net">conal@conal.net</a>&gt; writes:<br><br>&gt; On 1/10/07, Isaac Jones &lt;<a href="mailto:ijones@syntaxpolice.org">ijones@syntaxpolice.org</a>&gt; wrote:<br>&gt;
<br>&gt;&gt; ...<br>&gt;&gt; Remember: Cabal isn&#39;t only the build infrastructure, it&#39;s also the<br>&gt;&gt; metadata format that tools like Hackage use. If you decide to combine data<br>&gt;&gt; and code, you will no longer be able to manipulate the data with another
<br>&gt;&gt; tool.<br>&gt;&gt;<br>&gt;<br>&gt; I&#39;m worried and confused about this conclusion. I want to address my<br>&gt; confusion first, and maybe the worry will be handled.<br>&gt;<br>&gt; By &quot;data&quot; vs &quot;code&quot;, I&#39;m guessing you mean simple first-order values, and
<br>&gt; mainly strings, vs everything else (especially functions). But I wonder if<br>&gt; instead you mean any Haskell value (including functions) vs the content of a<br>&gt; .hs file?<br><br>I&#39;m not sure what you mean here.&nbsp;&nbsp;What I&#39;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 &quot;reading&quot; that package description from<br>another tool.<br><br>&gt; Maybe I&#39;d have a firmer grasp of this issue if I could had in mind an
<br>&gt; example of such a metadata-manipulating tool. Would someone please suggest<br>&gt; 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.&nbsp;&nbsp;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>&nbsp;&nbsp;isaac<br></blockquote></div><br>