Opened 14 months ago

Last modified 9 months ago

#15464 new bug

Template Haskell creates System names when it shouldn't

Reported by: goldfire Owned by:
Priority: normal Milestone: 8.10.1
Component: Template Haskell Version: 8.4.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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.)

Change History (2)

comment:1 Changed 14 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be fixed for in GHC 8.6.

comment:2 Changed 9 months ago by osa1

Milestone: 8.8.18.10.1

Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.