Template Haskell creates System names when it shouldn't
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 (closed), but I fault TH here, not #15380 (closed).)
Trac metadata
Trac field | Value |
---|---|
Version | 8.4.3 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Template Haskell |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |