#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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
