<div dir="ltr">Hello,<div style><br></div><div style>To me it seems that the dependency here is incorrect---as far as I understand, GHC does not need to parse Cabal files, so it should not depend on the code and the library to do so.</div>
<div style><br></div><div style>Furthermore, what is the overall architecture of the whole thing? My understanding has been that each implementation should have its own notion of a "package", and cabal simply has support for working with the package formats for each implementation. Thus, it seems that the package types and code for (de)serializing them should be in the implementation (i.e., GHC), not Cabal. I can see that it might make sense to have a common representation about package meta-data (e.g., names, versions, license, etc.), so perhaps these should all go in a separate package. This looks a bit like the `cabal-types` that Duncan suggested, but I'd imagine that Cabal would need more types than just package meta-data so this is not an ideal name.</div>
<div style><br></div><div style>Finally, I agree that a "real" parser is good, but do you really want to write it using Parsec? A sensible alternative would be to write a Happy grammar. Having an actual grammar would both benefit users of the system, and it would avoid the dependency on all those package. My experience of having to maintain some largish Parsec (and in general, combinator based) parsers, is that over the years the parsers get more and more complex, and are quite hard to maintain.</div>
<div style><br></div><div style>-Iavor</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br><br></div><div style><br></div><div style>
<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 6:14 AM, Duncan Coutts <span dir="ltr"><<a href="mailto:duncan.coutts@googlemail.com" target="_blank">duncan.coutts@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2013-03-18 at 12:43 +0000, Ian Lynagh wrote:<br>
> On Mon, Mar 18, 2013 at 12:34:16PM +0000, Duncan Coutts wrote:<br>
> ><br>
> > Then you can have ghc-pkg depend on Cabal and use that for the<br>
> > human-readable bits, but since that's a program then it doesn't expose<br>
> > the Cabal lib dependency. Then ghc (and hence the ghc lib) would not<br>
> > depend on Cabal, but it would need a copy of the InstalledPackageInfo<br>
> > type and the other types that it uses.<br>
><br>
> Right, exactly. But we don't want to have 2 copies of the types, so<br>
> could we move them into a Cabal-datatypes package which can be shared by<br>
> both Cabal and GHC please?<br>
<br>
</div>That would be a rather annoying split. The cabal-lib package itself is<br>
supposed to be just types + parsers + pretty printers (& related utils).<br>
It'd end up looking like:<br>
<br>
cabal-types:<br>
types: InstalledPackageInfo, PackageName, Version, PackageId,<br>
InstalledPackageId, License<br>
<br>
cabal-lib:<br>
parser for InstalledPackageInfo, PackageName, Version, PackageId,<br>
InstalledPackageId, License<br>
modules Distribution.*<br>
<br>
cabal-build-simple:<br>
modules Distribution.Simple.*<br>
<br>
It's not as if one could frame this as a "the aspects of the Cabal spec<br>
that compilers need" because the other impls will want the parser +<br>
printers as well.<br>
<span class="HOEnZb"><font color="#888888"><br>
Duncan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>