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

Duncan Coutts duncan at
Thu Mar 14 23:01:53 CET 2013

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. The grammar I've got now really isn't that
bad. In fact if we wanted to simplify it we'd rip out the bits that are
designed to make it easier to generate by programs: we'd eliminate the
explicit {} syntax and just use layout. Allowing either is what makes
the grammar more complex. But as I say, I'm satisfied that the grammar
is ok.

> I thought I heard someone say that most existing cabal files can be
> converted to valid yaml by adding one token at the start? If the change was
> that simple it might be doable. I think the trick is that we'd need to
> expose this by only treating the file as yaml if the minimum cabal version
> is >= 1.17 (or so).

I know people have compared it to yaml and suggested we just use yaml,
but I don't think it's that close syntactically. I did look into this
when I started and I think there are too many differences to make it
practical to switch to yaml (or a subset).

> In general these sorts of format changes are painful for users and I sense
> that now might be a bad time to change it (user morale is already a bit low
> with complaints of "cabal hell", let's not exacerbate that by breaking
> existing .cabal files).

Right. I'm satisfied the format is basically ok, we don't need any
breaking changes.

Duncan Coutts, Haskell Consultant
Well-Typed LLP,

More information about the cabal-devel mailing list