[GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses

[GHC]

#9658: Prettyprint constraints in type signatures can omit necessary parentheses
-------------------------------------+-------------------------------------
       Reporter:  Blaisorblade       |                   Owner:
           Type:  bug                |                  Status:  new
       Priority:  low                |               Milestone:  7.8.4
      Component:  GHCi               |                 Version:  7.8.3
       Keywords:                     |        Operating System:
   Architecture:  Unknown/Multiple   |  Unknown/Multiple
     Difficulty:  Easy (less than 1  |         Type of failure:  Other
  hour)                              |               Test Case:
     Blocked By:                     |                Blocking:
Related Tickets:                     |  Differential Revisions:
-------------------------------------+-------------------------------------
 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):

 {{{#!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:

 {{{#!hs
 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9658>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler