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

cabal exact-printer #7626

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

cabal exact-printer #7626

wants to merge 2 commits into from

Conversation

ptkato
Copy link
Collaborator

@ptkato ptkato commented Sep 7, 2021

Please include the following checklist in your PR:


This PR aims to centralise the efforts done toward our goal of coming up with a exact-printer for cabal.

Refer to #7544 for more detailed information and discussion.

@pranaysashank
Copy link

Should this go in the upcoming Cabal-Syntax package?

@@ -42,12 +44,14 @@ import Prelude ()
-- | A Cabal-like file consists of a series of fields (@foo: bar@) and sections (@library ...@).
data Field ann
= Field !(Name ann) [FieldLine ann]
| Comment !ann !(CommentLine ann)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Comments can be extracted separately? See how cabal-fmt does the job. (Also GHC AST is not polluted with comments, they are attached afterwards. That's why there is ann in the Field structure too).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just something I wrote for quick prototyping. I'll checkout both cabal-fmt and ghc-exactprint

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should keep in mind that most time this code is hit when solver is traversing dozens if not hundreds of cabal files. The less stuff is done in hot path, the more responsive cabal-install is.

The "interactive" usage should not make compromises to the primary function. I'd argue that if it becomes a friction then having two separate parsers is not impossible idea either.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... it's something to ponder; while having a solid base to build on top of is great, having a clean slate to shape the feature to our current needs, while not affecting the older code, is very appealing.

@ptkato
Copy link
Collaborator Author

ptkato commented Sep 8, 2021

@pranaysashank, likely, however it's best we wait (before moving anything) for #7620 to be merged first.

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 1, 2022
@ulysses4ever ulysses4ever removed the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 3, 2022
@nomeata
Copy link
Contributor

nomeata commented Jan 3, 2023

#7620 has been merged – what’s the status of this PR?

@Mikolaj
Copy link
Member

Mikolaj commented Jan 17, 2023

@ptkato: thanks for this version of the PR. Do you intend to work on it in the future?

@ptkato
Copy link
Collaborator Author

ptkato commented Jan 23, 2023

@Mikolaj I'd like to, but at the moment I can't tackle something this size.

@Mikolaj
Copy link
Member

Mikolaj commented Jan 24, 2023

@ptkato: thanks. No pressure, just asking.

I wonder if perhaps this can be split into smaller parts and tackled gradually by multiple people.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants