Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,248
    • Issues 5,248
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 564
    • Merge requests 564
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9658
Closed
Open
Issue created Oct 02, 2014 by Blaisorblade@trac-Blaisorblade

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking