Prettyprint constraints in type signatures can omit necessary parentheses

GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix.

The example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning-syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs):

num = inj . Num

> :t num
num :: NUM :<: sup => Int -> sup (Full Int)

Adding the type annotation in gives:

src/Syntactic.hs:115:20: parse error on input `=>'

To fix the parse error, I need to add parentheses around the constraint:

num :: (NUM :<: sup) => Int -> sup (Full Int)

(Here this happens to be the wrong type signature, but that's orthogonal).

I imagine that's just because the constraint uses an operator (probably only possible with TypeOperators).

This happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3.

Misc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD.

Trac metadata

Trac field	Value
Version	7.8.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	hvr
Operating system
Architecture