Fix some hlint suggestions #132
No reviewers
Labels
No Label
blocked: dependency
blocked: info-needed
bug
duplicate
enhancement
fixed in HEAD
help wanted
hs:arrows
hs:brackets
hs:classes
hs:comments
hs:do-notation
hs:guards
hs:lists
hs:operators
hs:patterns
hs:records
hs:types
invalid
language extension support
layouting
needs confirmation
priority: high
priority: low
question
revisit before next release
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: hexagoxel/brittany#132
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "master"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
How configurable is
hlint?There are some good changes in there, but many of these changes that save a few characters feel rather code-golfy and not worth the effort in my opinion. Take the removal of redundant
dos: For many of those cases, if the relevant code gets changed in the future, it is very likely that thedowill become non-redundant. And you gain nothing from saving a whitespace and two characters.I approve of anything that has to do with alignment, as that has a significant effect on readability.
For other stuff I really don't see the point in even reviewing the individual cases. Sorry.
I'd like to also give an example of something that would be rather useful to improve in regards to general readability of the layouter's code. This function:
is used often, but the argument being a list of tuples produces ugly code/formatting wherever it is used. There is a different approach that was also mentioned in one
reddit/r/haskelldiscussion recently. What if instead ofwhich is rather annoying to read, we could write something like
This seems to much clearer syntactically, with the downside of having a bit more mental overhead (because we use yet another Monad). But I think that trade-off is worth it, especially with speaking names
runFilteredAlternativeandaddAlternativeCond(and not justrunWriter- it is mostly a Writer, right?).Maybe you could explore this a bit?
Thanks for prompt repsonse! The
hlintis pretty configurable - each suggestion can be disabled individually and config can be added into the repository.Regarding
dos I'd agree as they're pretty harmless. Yet, on the other hand, redundant parens,$s or replacement offmap f $byf <$>does feel like a good thing - the less operators the better. I do understand that there's quite a few changes and it's tiresome to review them one by one. But on the other hand some changes help to bring constistency to the code, which IMO does improve readability further.Regarding
docAltFilterI did notice this pattern and it strikes me as unwieldy. Let me try and see whether I can come up with a nice monad like you're proposing. It indeed does sound like a simpleWritermonad at its core.@lspitzner Returning to your example for replacement of
docAltFilter. What do you think about using operators to tie condidion and expression? E.g. instead ofwrite something like
Could you disable the redundant-do part then? I think all other hlint changes I am fine with.
It looks cool for sure, however: This particular operator looks a lot like case/guard syntax, where only ever one of the alternatives gets selected - but that is not the case here. And having to use
otherwisefeels like a downside too, when we really mean to express "always". I am not entirely convinced yet :-)I have split initial commit into single commit for each hint, added hlint config that disables
Redundant doand a couple of other suggestions and replaceddocAltFilterwithrunFilteredAlternativeas suggested.The Semigroup commit will be useful for upgrade to ghc 8.4.
Thanks, i see you refactored things is Decl.hs some more and you even updated some commented-out stuff. I think this really helps readability.
I have commented on some few things i noticed. Really nothing serious, but if you don't mind one last iteration.
@ -415,8 +422,20 @@ docExt x anns shouldAddComment = allocateNode $ BDFExternaldocAlt :: [ToBriDocM BriDocNumbered] -> ToBriDocM BriDocNumberedI don't really see the usecase for this, and one might expect the same pattern as with
when/whenM:(Also it is not used anywhere afaict.)
@ -309,2 +309,4 @@(docForceSingleline . return <$> gs))wherePart = case mWhereDocs ofNothing -> Just docEmptycould you move this let up in group with the previous let-binds?
add comment
@ -121,25 +118,22 @@ layoutLLIEs :: Bool -> Located [LIE RdrName] -> ToBriDocM BriDocNumberedlayoutLLIEs enableSingleline llies = doCan factor out
runFilteredAlternative $out of thecases.@ -415,8 +422,20 @@ docExt x anns shouldAddComment = allocateNode $ BDFExternaldocAlt :: [ToBriDocM BriDocNumbered] -> ToBriDocM BriDocNumberedIndeed it's not used anywhere. I think I tried to use it somewhere but found a way without it.
@ -309,2 +309,4 @@(docForceSingleline . return <$> gs))wherePart = case mWhereDocs ofNothing -> Just docEmptyDone.
@ -121,25 +118,22 @@ layoutLLIEs :: Bool -> Located [LIE RdrName] -> ToBriDocM BriDocNumberedlayoutLLIEs enableSingleline llies = doDone.
@ -309,2 +309,4 @@(docForceSingleline . return <$> gs))wherePart = case mWhereDocs ofNothing -> Just docEmptyDone.
I have addressed your suggestions. Please review.
Thanks! I'd never have noticed that cabal file duplication :-)