Advance notice that I'd like to make Cabal depend on parsec

[Iavor Diatchki]

Hello,

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.

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.

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.

-Iavor













On Mon, Mar 18, 2013 at 6:14 AM, Duncan Coutts <duncan.coutts at googlemail.com
> wrote:

> On Mon, 2013-03-18 at 12:43 +0000, Ian Lynagh wrote:
> > On Mon, Mar 18, 2013 at 12:34:16PM +0000, Duncan Coutts wrote:
> > >
> > > Then you can have ghc-pkg depend on Cabal and use that for the
> > > human-readable bits, but since that's a program then it doesn't expose
> > > the Cabal lib dependency. Then ghc (and hence the ghc lib) would not
> > > depend on Cabal, but it would need a copy of the InstalledPackageInfo
> > > type and the other types that it uses.
> >
> > Right, exactly. But we don't want to have 2 copies of the types, so
> > could we move them into a Cabal-datatypes package which can be shared by
> > both Cabal and GHC please?
>
> That would be a rather annoying split. The cabal-lib package itself is
> supposed to be just types + parsers + pretty printers (& related utils).
> It'd end up looking like:
>
> cabal-types:
>   types: InstalledPackageInfo, PackageName, Version, PackageId,
> InstalledPackageId, License
>
> cabal-lib:
>   parser for InstalledPackageInfo, PackageName, Version, PackageId,
> InstalledPackageId, License
>   modules Distribution.*
>
> cabal-build-simple:
>   modules Distribution.Simple.*
>
> It's not as if one could frame this as a "the aspects of the Cabal spec
> that compilers need" because the other impls will want the parser +
> printers as well.
>
> Duncan
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130318/05cbf1c9/attachment-0001.htm>