[GHC] #15464: Template Haskell creates System names when it shouldn't

GHC ghc-devs at haskell.org
Wed Aug 1 18:54:07 UTC 2018


#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


More information about the ghc-tickets mailing list