<div dir="ltr">I'd love to have a proper parser and source-location-aware AST for sake of editor/IDE tools, so +1 from me. If you don't end up doing this after all, I'd still like to see your parser in a separate package, although I understand if you don't feel like maintaining two parsers especially given the tedious process for verifying they work similarly. I guess it could still be useful in the same way we find haskell-src-exts useful despite some incompatibilities with GHC.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 3:53 PM, 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">Hi folks,<br>
<br>
I want to give you advance notice that I would like to make Cabal depend<br>
on parsec. The implication is that GHC would therefore depend on parsec<br>
and thus it would become a core package, rather than just a HP package.<br>
So this would affect both GHC and the HP, though I hope not too much.<br>
<br>
The rationale is that Cabal needs to parse things, like .cabal files and<br>
currently we do not have a decent parser in the core libraries. By<br>
decent I mean one that can produce error messages with source locations<br>
and that doesn't have unpredictable memory use. The only parser in the<br>
core libraries at the moment is Text.ParserCombinators.ReadP from the<br>
base package and that fails my "decent" criteria on both counts. Its<br>
idea of an error message is (), and on some largish .cabal files we take<br>
100s of MB to parse (I realise that the ReadP in the base package is a<br>
cutdown version so I don't mean to malign all ReadP-style libs out<br>
there).<br>
<br>
Partly due to the performance problem, the terrible .cabal file error<br>
messages, and partly because Doaitse Swierstra keeps asking me if .cabal<br>
files have a grammar, I've been writing a new .cabal parser. It uses an<br>
alex lexer and a parsec parser. It's fast and the error messages are<br>
pretty good. I have reverse engineered a grammar that closely matches<br>
the existing parser and .cabal files in the wild, though I'm not sure<br>
Doaitse will be satisfied with the approach I've taken to handling<br>
layout.<br>
<br>
Why did I choose parsec? Practicality dictates that I can only use<br>
things in the core libraries, and the nearest thing we have to that is<br>
the parser lib that is in the HP. I tried to use happy but I could not<br>
construct a grammar/lexer combo to handle the layout (also, happy is not<br>
exactly known for its great error messages).<br>
<br>
I've been doing regression testing against hackage and I'm satisfied<br>
that the new parser matches close enough. I've uncovered all kinds of<br>
horrors with .cabal files in the wild relying on quirks of the old<br>
parser. I've made adjustments for most of them but I will be breaking a<br>
half dozen old packages (most of those don't actually build correctly<br>
because though their syntax errors are not picked up by the parser, they<br>
do cause failure eventually).<br>
<br>
So far I've just done the outline parser, not the individual field<br>
parsers. I'll be doing those next and then integrate. So this change is<br>
still a bit of a ways off, but I thought it'd be useful to warn people<br>
now.<br>
<br>
Duncan<br>
<br>
<br>
_______________________________________________<br>
cabal-devel mailing list<br>
<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/cabal-devel" target="_blank">http://www.haskell.org/mailman/listinfo/cabal-devel</a><br>
</blockquote></div><br></div>