[GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names

#14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you look at the Haddocks for, e.g., the `singletons` package, one sees dozens of signatures containing unsightly names containing long integers. For instance, in the equation list for `Data.Singletons.Prelude.Either.IsLeft` we have {{{ IsLeft (Left _z_6989586621679437436) = TrueSym0 IsLeft (Right _z_6989586621679437439) = FalseSym0 }}} For definitions with lots of variables things quickly become unreadable. These names appear this way because they are generated by TemplateHaskell's `newName` function. This name is ultimately converted to a GHC `System` name by `Convert.thRdrName`. Such `Name`s are then pretty- printed including their uniques (see `Name.pprSystem`). I'm not sure I see the rationale for this. Surely if the names are tidied properly (e.g. using `TyConRep.tidyType`) there should be no need for the unique suffix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14436 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This may be unique to `singletons`. See [https://github.com/goldfirere/th- desugar/blob/master/Language/Haskell/TH/Desugar/Util.hs#L46 `newUniqueName`], which uses `newName`, `show`s it, and then uses the result to make ''another'' `newName`. This is necessary because these `newName`d entities are sometimes top-level, and GHC doesn't like two top- level entities to have the same `OccName`. I suppose this is really a workaround for an unreported GHC bug, but I don't think the bug is the one this ticket is really worried about. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14436#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Ahh, then perhaps my analysis is faulty. Let's forget this happened then. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14436#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC