-
Notifications
You must be signed in to change notification settings - Fork 841
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
pretty up src/Stack/Package.hs
#3384
pretty up src/Stack/Package.hs
#3384
Conversation
Hmm, somehow I thought there was more to do in that module. This might be less WIP than I thought. I still haven't really reviewed my work though, and there's a few TODOs I added that I can maybe resolve if I look around a bit. Will try to do that tomorrow. |
3fa7078
to
312f14d
Compare
src/Stack/Package.hs
src/Stack/Package.hs
LGTM! Just one comment to address. I like the |
src/Stack/Package.hs
Outdated
where | ||
dispPoss = styleFile . fromString . toFilePath |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think display
can be used instead because there is an instance for Path t File
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch, thanks!
Did that one change, nice catch. Cool, thanks. Was hoping that |
showName (DotCabalMain fp) = fp | ||
showName (DotCabalFile fp) = fp | ||
showName (DotCabalCFile fp) = fp | ||
dispOne = fromString . toFilePath |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunate, I can't figure out exactly why this can't be display
instead of dispOne
in this function. I get the error:
• Couldn't match type ‘Ann (Path b t)’ with ‘AnsiAnn’
Expected type: Path b t -> AnsiDoc
Actual type: Path b t -> Doc (Ann (Path b t))
• In the first argument of ‘map’, namely ‘display’
In the first argument of ‘bulletedList’, namely
‘(map display rest)’
In the second argument of ‘(<>)’, namely
‘bulletedList (map display rest)’
• Relevant bindings include
rest :: [Path b t] (bound at src/Stack/Package.hs:1146:29)
candidate :: Path b t (bound at src/Stack/Package.hs:1146:19)
warnMultiple :: DotCabalDescriptor
-> Path b t -> [Path b t] -> m ()
(bound at src/Stack/Package.hs:1146:1)
when I try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Must be something about Path b t
being polymorphic? A little confused. Adding a Display (Path b t)
constraint to the function type doesn't help either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's because it's polymorphic. I think adding Display (Path b t)
to the function's constraints should solve the problem. Alternatively, just make it monomorpic, I think it's just used for (Path Abs File)
or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, thanks for looking at it. I thought I tried that constraint and got the same error. Very possible I screwed it up though. I'll investigate more.
LGTM. Nice idea to use hlint for this! Though, I think there could be cases where Will need to be updated due to changes merged in #3389 |
showName (DotCabalMain fp) = fp | ||
showName (DotCabalFile fp) = fp | ||
showName (DotCabalCFile fp) = fp | ||
dispOne = fromString . toFilePath |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's because it's polymorphic. I think adding Display (Path b t)
to the function's constraints should solve the problem. Alternatively, just make it monomorpic, I think it's just used for (Path Abs File)
or something.
95eb29d
to
1ee0583
Compare
Thanks! Yeah, hopefully not many. If there's only a few we can just add exceptions for them. Can definitely re-evaluate if they pop up all over.
Hopefully just did that, crossing fingers for the CI builds. Edit: hmm, not going to build. Will have a bit more work to do unfortunately. Need to either make the pretty* function types more general, or make a lot of the functions in s/S/Package.hs more specific. Or something. |
Generalizing to something like |
Needed for using them in contexts like in s/S/Package.hs.
1ee0583
to
0722dd5
Compare
Yep, that seemed to do the trick, thanks. Now to investigate that |
Cool, looks like CI is passing, feel free to merge this. |
That works, I'll just come back to the On to finishing up terminal detection I hope :) |
Use
$pretty*
functions where appropriate insrc/Stack/Package.hs
.Related to #2650
b85364d is probably the commit most in need of review, had to do some things I barely understood to get that working.