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

Duncan Coutts duncan at
Fri Mar 15 16:33:24 CET 2013

On Fri, 2013-03-15 at 05:19 +0100, Bardur Arantsson wrote:
> On 03/14/2013 11:01 PM, Duncan Coutts wrote:
> > On Thu, 2013-03-14 at 11:15 -0700, Jason Dagit wrote:
> >> On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson <spam at>wrote:
> >>
> >>> On 03/14/2013 03:53 PM, Duncan Coutts wrote:
> >>>> Hi folks,
> >>>>
> >>>> Why did I choose parsec? Practicality dictates that I can only use
> >>>> things in the core libraries, and the nearest thing we have to that is
> >>>> the parser lib that is in the HP. I tried to use happy but I could not
> >>>> construct a grammar/lexer combo to handle the layout (also, happy is not
> >>>> exactly known for its great error messages).
> >>>>
> >>>
> >>> Just thinking out loud here, but what about ditching the current format
> >>> for something that's simpler to parse/generate? Like, say, JSON?
> > 
> > Of course .cabal files are mainly written by humans, not machines, so we
> > should optimise for them.
> I though we were mostly talking about InstalledPackageInfo. That could
> be in $EASILY_PARSEABLE_FORMAT without really breaking anything, right?

In principle it could be any format. But it is a format specified in the
Cabal spec, and shared between all the Haskell implementations. Unless
there's a compelling reason to change all that, I'd rather not.

> Another option if GHC really also needs to parse .cabal files:

That's ok, it doesn't. GHC use Cabal when building ghc, but at runtime
it's just using the InstalledPackageInfo type, parser (and perhaps some
index utils).

Duncan Coutts, Haskell Consultant
Well-Typed LLP,

More information about the cabal-devel mailing list