Use type signature: Don't insert excess parentheses .

[AndreasPK]

When completing a type signature HLS is very conservative and always adds parentheses around the actual type.

For example something like myHead :: [a] -> _ will get a type of myHead :: [a] -> (a). Note the parentheses around the a.

While I personally don't have a big problem with this. Many of my colleagues insist on them being removed. Which usually makes these signatures easier to read!

Describe the solution you'd like

Ideally I would like the inserted type signature to be the one with the least parentheses. For example Just _ will require braces if the inserted type is Either Int Char. But if it's just Char there is no need for them. But in something like a -> _ -> ... then we can get away without braces for Either Int Char!

It's likely not trivial to achieve this. But it would be really nice.

[googleson78]

Could look at what hlint does for some inspiration/reuse - https://github.com/ndmitchell/hlint/blob/master/src/GHC/Util/Brackets.hs#L17

[googleson78]

Hm, is something like the Brackets class perhaps worthy of going into ghc-lib-parser-ex, @shayne-fletcher?

[shayne-fletcher]

Hm, is something like the Brackets class perhaps worthy of going into ghc-lib-parser-ex, @shayne-fletcher?

i appreciate the appeal but there was a consciously and carefully drawn line between hlint and ghc-lib-parser-ex that this would definitely cross cc @ndmitchell

[ndmitchell]

There are lots of utility functions that can have a strong and clear spec written for them. Alas, Brackets is not one. For example, most Haskell users would consider x + (y{a+b}) to have required brackets, when in fact they are redundant. As soon as the Brackets class needs to encode custom logic about when/where to trim brackets, and if you are looking to clean up obviously redundant brackets, or have a semantic encoding etc, it starts to end up with a more complex design. That's not to say that something akin to brackets couldn't end up in a shared library, but it needs more design (does it report brackets that are redundant, strictly, or what, how does it deal with the context it is going in to) and once it has that level of design, does it really belong in ghc-lib-parser-ex, which is otherwise quite design-free?

In the end, I suspect it's easier to just write a quick traversal to remove obviously unnecessary brackets for the cases you care about. It's probably about 5 lines of code with SYB or Uniplate.

[xsebek]

Hey @AndreasPK, I took a look at the code that was adding the parentheses and I can't blame it since it only has a Text hint to go on. There was even a helpful comment explaining the situation.

My change could help with your head but for the second case, I would probably need to pull in more info (the Diagnostic type may not show surrounding code). I would be interested in any tips or improvements. 🙂