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 |