Use ghc-lib-parser with stylish-haskell #293
Conversation
|
At this point I am starting to feel like it is good enough for review and potentially to merge as a good step in the right direction ✌️ |
|
Thanks @jaspervdj! I fixed all the CI issues now and so this should be in pretty good shape. Looking forward to your review! |
felixmulder
changed the title
| showOutputable :: GHC.Outputable a => a -> String | ||
| showOutputable = GHC.showPpr baseDynFlags | ||
|
|
||
| compareOutputable :: GHC.Outputable a => a -> a -> Ordering |
There was a problem hiding this comment.
Do we have any other orderings in use? If not maybe it would make sense to extract this to an orphan Ord instance for GHC.Outputable and not use this one explicitly?
There was a problem hiding this comment.
This is mostly used in the imports step. I think it might be a good idea here to invent our type for imports that carries the information we need. This'll probably be nice when we add support for merging imports - so then we add the ordering instance for that type.
WDYT?
There was a problem hiding this comment.
So I did two things, I changed the newtype representation of:
newtype Imports = Imports [LImportDecl GhcPs]
-- to:
newtype Import = Import (ImportDecl GhcPs)This makes things a bit easier to reason about, it was possible to define equality for the import individually and I think it'll give us a more intuitive API down the line to work with imports. E.g. I added a helper function canMergeImport which is used in the equality instance. This helper could be used in the Imports step to merge imports - and get better ordering... I think I'm gonna play with that a bit today
There was a problem hiding this comment.
@lukasz-golebiewski @felixmulder
Do we have any other orderings in use? If not maybe it would make sense to extract this to an orphan
Ordinstance forGHC.Outputableand not use this one explicitly?
This thread caught my eye as I perused this ticket. It looks to me that these lines are covering the same ground as ghc-lib-parser-ex's HsExtendInstances wrapper. I've mused before that ghc-lib-parser-ex might be useful for stylish-haskell to use/extend on its conversion from haskell-src-exts to ghc-lib-parser - would be nice to share these sorts of common utilities with e.g. HLint!
There was a problem hiding this comment.
Hmm c.f. showOutputable :: GHC.Outputable a => a -> String with unsafePrettyPrint (from Language.Haskell.GhclibParserEx.GHC.Utils.Outputable) too.
There was a problem hiding this comment.
I think that'd be neat 👍
There was a problem hiding this comment.
I think that'd be neat 👍
Let's let this land and revisit. If you're open to it moving some of this down to ghc-lib-parser-ex, I think we can eliminate this file at least in entirety.
There was a problem hiding this comment.
I see also that Module.hs has quite a lot of overlap with code under GHC/Util in HLint (e.g. parsing out language pragmas); most code in there hasn't been deemed general enough before now to get pulled down into ghc-lib-parser-ex but I'm starting to see opportunities to coalesce on it now.
|
@felixmulder I spoke to @VBeatrice and the current plan is for her to finish the Align step. After that we can merge the Squash and Align steps from GSoC into your work. Finally, we'll probably need to do some remaining bits (the |
|
@jaspervdj - sounds good to me 👍 There are a couple of systemic things that I think we should keep in mind moving forward: Comments are a pain in the rear. I think we basically have two choices here:
The former puts the onus on the implementer to get comments right for their step. It does give more precision and maybe better formatting(?). However, it's pretty darn error prone since there are so many edge cases. It could be abstracted into the printer monad. Which makes it easier for the implementer, and arguably - if we want to move line-wrapping into the printer monad, it might make that job easier as well. Not sure either way is preferable right now, but I don't think we're painting ourselves into a corner either way. The testing covers things fairly well at this point and our monorepo has >50kLOC that we're running this branch of stylish on for each commit since a few weeks back. |
|
GSoC is over for this year. I'll be working on merging in these changes and doing some final checks this week / weekend. |
|
Merged in 250e709, thanks again to everyone involved! |
This PR contains the following:
OptionsconfigurationThis is at the point where I think we should start discussing the changes.
Known issues
Does not support GADTs yet (should be quite trivial)EDIT: Basic GADT support is now includedHaven't implemented getting rid of redundant language pragmasScope of PR
I'll be happy to fix most of these issues, but I'm not too keen on doing:
OptionsdatatypeImplement removal of redundant language pragmasImprovements to be had
Since this PR lays the foundation of having a context aware printer monad, we should be able to use it in order to have automatic line breaking etc at appropriate times. I think it's a huge improvement!