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
do
s: For many of those cases, if the relevant code gets changed in the future, it is very likely that thedo
will 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/haskell
discussion 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
runFilteredAlternative
andaddAlternativeCond
(and not justrunWriter
- it is mostly a Writer, right?).Maybe you could explore this a bit?
Thanks for prompt repsonse! The
hlint
is pretty configurable - each suggestion can be disabled individually and config can be added into the repository.Regarding
do
s 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
docAltFilter
I 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 simpleWriter
monad 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
otherwise
feels 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 do
and a couple of other suggestions and replaceddocAltFilter
withrunFilteredAlternative
as 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 $ BDFExternal
docAlt :: [ToBriDocM BriDocNumbered] -> ToBriDocM BriDocNumbered
I 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 of
Nothing -> Just docEmpty
could you move this let up in group with the previous let-binds?
add comment
@ -121,25 +118,22 @@ layoutLLIEs :: Bool -> Located [LIE RdrName] -> ToBriDocM BriDocNumbered
layoutLLIEs enableSingleline llies = do
Can factor out
runFilteredAlternative $
out of thecase
s.@ -415,8 +422,20 @@ docExt x anns shouldAddComment = allocateNode $ BDFExternal
docAlt :: [ToBriDocM BriDocNumbered] -> ToBriDocM BriDocNumbered
Indeed 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 of
Nothing -> Just docEmpty
Done.
@ -121,25 +118,22 @@ layoutLLIEs :: Bool -> Located [LIE RdrName] -> ToBriDocM BriDocNumbered
layoutLLIEs enableSingleline llies = do
Done.
@ -309,2 +309,4 @@
(docForceSingleline . return <$> gs)
)
wherePart = case mWhereDocs of
Nothing -> Just docEmpty
Done.
I have addressed your suggestions. Please review.
Thanks! I'd never have noticed that cabal file duplication :-)