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

Migrate cabal.project parsing to parsec #7748

Open
gbaz opened this issue Oct 14, 2021 · 4 comments
Open

Migrate cabal.project parsing to parsec #7748

gbaz opened this issue Oct 14, 2021 · 4 comments
Labels
cabal-install: nix-local-build re: code quality Internal issue: concerning code quality / refactorings type: refactor

Comments

@gbaz
Copy link
Collaborator

gbaz commented Oct 14, 2021

Cabal.project parsing goes through legacy parsers and has a legacy -> current step. Its all rather awkward and also makes figuring out the actual grammar pretty difficult. It would be good to clean this up, capture the current grammar properly, and go through modern parsec parsers.

@gbaz gbaz added cabal-install: nix-local-build type: refactor re: code quality Internal issue: concerning code quality / refactorings labels Oct 14, 2021
@ptkato
Copy link
Collaborator

ptkato commented Oct 14, 2021

I think this could be tied to the exact printing work. A project file doesn't differ much, in terms of how it's written, from a cabal file.

@gbaz
Copy link
Collaborator Author

gbaz commented Oct 14, 2021

Well, maybe. As it is, we don't have any sane parsing at all. It would be nice to reuse as much of the cabal parsing machinery as possible, treating projects as a special grammar, at which point we could leverage the exact-print stuff.

@phadej
Copy link
Collaborator

phadej commented Oct 14, 2021

The challenge is not using some specific new framework, as parsing the project file would be something like

grammar :: ParsecFieldGrammar Project Project
grammar = Project
    <$> C.monoidalFieldAla "packages"          (C.alaList' C.FSep PackageLocation) prjPackagesL
    <*> C.monoidalFieldAla "optional-packages" (C.alaList' C.FSep PackageLocation) prjOptPackagesL
    <*> C.monoidalFieldAla "constraints"       (C.alaList' C.CommaVCat NoCommas)   prjConstraintsL
    <*> C.monoidalFieldAla "allow-newer"       (C.alaList' C.CommaVCat NoCommas)   prjAllowNewerL
    <*> C.booleanFieldDef  "reorder-goals"                                         prjReorderGoalsL False
    <*> C.optionalFieldAla "max-backjumps"     Int'                                prjMaxBackjumpsL
    <*> C.optionalFieldDef "optimization"                                          prjOptimizationL OptimizationOn

... but actually figuring out what should or shouldn't be parsed.

The cabal.project parser reuses parts ~/.cabal/config parsing, there is some magic tying command line parsing in as well.

It's very messy, and not specified, there are only examples and some stuff which works, maybe intentionally, maybe accidentally.

I wouldn't tie exact print work with this. They are different challenges.

(EDIT: Just replicating what the current code does may be beneficial, already but i'm sure there are plenty of low-mid hanging cleanup&improvement opportunities).

@mmhat
Copy link

mmhat commented Aug 15, 2023

I think this can be closed since it is a duplicate of #6101.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cabal-install: nix-local-build re: code quality Internal issue: concerning code quality / refactorings type: refactor
Projects
None yet
Development

No branches or pull requests

4 participants