Skip to content

Source-location aware parser for package descriptions #1127

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

Open
dag opened this issue Nov 21, 2012 · 9 comments
Open

Source-location aware parser for package descriptions #1127

dag opened this issue Nov 21, 2012 · 9 comments

Comments

@dag
Copy link

dag commented Nov 21, 2012

It would be nice if Cabal included a parser for .cabal files that remembers line and column numbers for parsed entities. This could then be used by tools like packdeps to give the source location for an outdated dependency, and in turn used in text editors to annotate lines with information from packdeps when editing a .cabal file.

More broadly, it would be nice to have an exact-printer for the relevant AST, to make it possible to write tools that process .cabal files programmatically without messing up their formatting.

@UnkindPartition
Copy link
Contributor

This (an exact parser/printer) is something I would also like to see.

I may work on it eventually, but it's not high on my priority list.

@23Skidoo
Copy link
Member

It would be also nice to have the same for config files.

@dcoutts
Copy link
Contributor

dcoutts commented Nov 12, 2013

I have a new parser (for .cabal files and config files). The only problem is it needs parsec which currently we cannot depend on because it causes problems for GHC. There is however a plan to get GHC to not depend on Cabal, or rather have the ghc lib not depend on Cabal, only ghc-pkg & the build system. This may allow us to depend on parsec and so we could have a fast and nice new parser.

@dag
Copy link
Author

dag commented Nov 12, 2013

A silly thought: is ReadP too weak for this?

@dcoutts
Copy link
Contributor

dcoutts commented Nov 12, 2013

ReadP is what we use now. It's terrible. It has no error reporting and no source locations. It's also slow.

@byorgey
Copy link
Member

byorgey commented Nov 13, 2013

@dcoutts: Exciting! (A patient sort of excitement.)

@erikd
Copy link
Member

erikd commented Dec 10, 2014

I understand why we can't currently use Parsec for tthis, but would it be possible to use alex and happy? Obviously not as elegant as Parsec but probably better than ReadP.

@ezyang
Copy link
Contributor

ezyang commented Feb 6, 2017

@phadej has been working on a Parsec parser which will make this easier, but if we decide to modify GPD to store this information that is a fairly major breaking change. One possibility is to store the data out of line in a data structure of its own (similar to how API annotations in GHC work.)

CC commercialhaskell/stackage#871
CC @rvion

@ulysses4ever
Copy link
Collaborator

I wonder how this is related to #7544 (if anyhow). Maybe it's superceded by #7544?..

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

10 participants