#15464: Template Haskell creates System names when it shouldn't -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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 we desugar {{{ [d| foo :: a -> a foo x = x |] }}} we discover that `a` has a "system" name. This is explained in this Note (is DsMeta): {{{ Note [Scoped type variables in bindings] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider f :: forall a. a -> a f x = x::a Here the 'forall a' brings 'a' into scope over the binding group. To achieve this we a) Gensym a binding for 'a' at the same time as we do one for 'f' collecting the relevant binders with hsSigTvBinders b) When processing the 'forall', don't gensym The relevant places are signposted with references to this Note }}} The problem is that the gensym approach creates system names, as explained further in `Note [Binders in Template Haskell]` in Convert. Essentially, it explains why to use system names as the result of `qNewName`, which !DsMeta uses for its gensyms. There is a good logic to this approach, but system names are just wrong in the quote above. This can be user-visible when we print out the results, as we see in test case `th/T10267`, which includes silliness like `j :: forall a0. a0 -> a0`. (Recall that GHC appends a `0` to system names when printing.) I worry that the answer here is a new `NameFlavour`, but perhaps cooler heads will prevail. (This problem became user-visible with the fix to #15380, but I fault TH here, not #15380.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15464 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler