#5375: Regression in newName ----------------------------------------+----------------------------------- Reporter: reinerp | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.2.1 Component: Template Haskell | Version: 7.3 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by LouisWasserman):
* cc: wasserman.louis@… (added) Comment: "Also, the "totally fresh" semantics you want has narrow usefulness, because it can never be referred to anywhere outside that immediate quotation. You data constructor D, for example, could not be referred to from anywhere else (and could not be exported from the module) under the semantics you propose." I wanted to point out my use case for exactly these semantics, and I think that it's more common than you seem to suggest. This bug broke my package unpack-funcs. I generated class instances with an associated data type, and for that data type, I *did* want a data constructor that couldn't be exported from the model or referred to anywhere else, because I wanted the only access to be via the functions in the type class. Instead, what I got was that I couldn't generate multiple class instances, because after the change to newName, the data constructors in each instance started conflicting! As it stands, it seems like the only way around this is the dirty, dirty hack of generating unique names with an unsafePerformIO'd global IORef for a unique ID counter. It's really depressing. =( -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5375#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs