[GHC] #10599: Template Haskell doesn't allow `newName "type"`

[GHC]

#10599: Template Haskell doesn't allow `newName "type"`
-------------------------------------+-------------------------------------
        Reporter:  meteficha         |                   Owner:  goldfire
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.12.1
       Component:  Template Haskell  |                 Version:  7.10.2-rc2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by GregWeber):

 >  So when you say newName "type", the variable's name really is type, but
 because it comes from newName, GHC prints it specially, as it's different
 from any other variable named type. So what you're trying to do -- create
 a variable named type -- is objectionable

 This isn't the goal here. If it was, `mkName` would be used.

 > It seems to me that we should be closing up the cases where type can be
 used as a name, not opening more of these holes. It would be quite
 confusing to the user if they end up with a situation where a they see an
 export named type, find that it can be imported without trouble if
 qualified, and then try to define another similarly named definition
 without of TH, only to find that they get a syntax error.

 Again, "type" is not being used for a name but instead to seed a new name

 From a TH user perspective it seems that in 7.10 `newName` has become a
 leaky abstraction where I am forced to understand how GHC is internalizing
 these names in a way that is different than what is printed out.

 As a library author, I can certainly work around this. But it isn't
 something I would think to test and I only found out about it when a user
 reported that their program stopped working on 7.10. So at this point
 there is no way for us to quantify the breakage it would cause. I would
 expect it to be fairly rare that a name gets into a TH function that is
 reserved as an identifier: for persistent this happens because it later
 adds a record field prefix to the name before generating a record field.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10599#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler