#5375: Regression in newName
---------------------------------+------------------------------------------
Reporter: reinerp | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.2.1
Component: Template Haskell | Version: 7.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
---------------------------------+------------------------------------------
Changes (by simonpj):
* cc: kfisher@… (added)
Comment:
I'm quite reluctant to introduce a third option on the spur of the moment.
The intended semantics of `newName` has not changed; it simply had a bug
before. The fact that quotation syntax is syntactic sugar for `newName`
was, for example, stated explicitly in the
[http://research.microsoft.com/~simonpj/tmp/notes2.ps TH2 note] (section
4.2). The distinction between `newName` and `mkName` is already subtle
enough, without adding a third variant to explain.
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.
Really the only significant shortcoming of the status quo is that you
can't make a data type that is local to a single splice and is totally
invisible outside it. (Actually you can get close by using a long name or
a random number, but those are really only approximations.)
Before doing the Real Work it would take (eg adding a new constructor to
`TH.Syntax.Name`, I'd need to be convinced that it was really all worth
it.
Does anyone else have an opinion? I'm adding Kathleen to the cc in case
it rings a bell with her.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5375#comment:7>
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
