#13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): My apologies, I was mistakenly under the impression that `NameU`s weren't exact. As for the idea of having GHC accept collisions between two `Exact` names with the same `nameBase` but different uniques... the idea still makes me a little bit queasy. I can think of a couple of unfortunate consequences of permitting this: 1. The fact that the program in comment:9 would still be ambiguous. Allowing `newName` to create valid top-level names means that you can effectively only use them from Template Haskell code in the event you use `newName` to create multiple copies of the same name. If you did such a thing, any attempt to use one copy of the name would result in ambiguity. This means that exporting them, importing them, using them in user- written source code, etc. is a no-go. This really feels like the wrong design to me—we shouldn't be encouraging the use of such a fragile mechanism. 2. How will Haddock render two top-level names with the same `nameBase` generated with two different calls to `newName`? Haddock would pretty much have to render the same function names twice, which is bound to cause confusion for readers. On the other hand `newGlobalName` would not be subject to these flaws. Because names produced by `newGlobalName` are truly unique (due to the suffix attached to them), no problems emerge from calling `newGlobalName` twice with the same `nameBase`. (I'm aware that programs like comment:9 aren't the intended //purpose// of `newGlobalName`, but it would be nice to rule out such tomfoolery by construction.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler