Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite the cabal file parser using parsec #2865

Closed
phadej opened this issue Oct 12, 2015 · 4 comments
Closed

Rewrite the cabal file parser using parsec #2865

phadej opened this issue Oct 12, 2015 · 4 comments
Assignees

Comments

@phadej
Copy link
Collaborator

phadej commented Oct 12, 2015

The existing parser has no formal grammar, has terrible error messages and is sometimes very slow and memory hungry. In large part this is because ReadP is a terrible parser. Now that the ghc library no longer depends on the Cabal library, Cabal is now allowed to depend on parsec.

The Cabal parser is two-stage, outline then individual fields. This approach will remain. There is a prototype new parser (with a grammar!) using parsec for the outline phase which has had some significant testing (the new grammar only rejects a very small number of old quirky .cabal files). This new parser needs to be integrated and tested further. Additionally the infrastructure for parsing the individual fields needs to be rewritten to use parsec.

@23Skidoo
Copy link
Member

23Skidoo commented Jun 8, 2017

This ticket should be either closed or updated to reflect the current state of affairs.

@phadej
Copy link
Collaborator Author

phadej commented Jun 10, 2017

@23Skidoo, briefly the next steps are

  • Setup parsec (mtl and text) into GHC tree
  • Rip-off non-parsec stuff from Cabal
  • ...
  • Profit

But I don't want to bother @bgamari on this before GHC-8.2.1 is out.

@BardurArantsson
Copy link
Collaborator

... and then upgrade to Megaparsec? :)

(Sorry, couldn't resist.)

@hvr
Copy link
Member

hvr commented Jun 11, 2017

@BardurArantsson that's a fair point :-) the main reason to stick with parsec right now is IMO that its dependency footprint is lighter, and given it's going to become a GHC bundled library, it's a good thing that parsec is so mature by now that its development has slowed down (while megaparsec is actively evolving). ;-)

@phadej phadej closed this as completed Nov 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants