#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 goldfire): Replying to [comment:5 bgamari]:
It would be quite confusing to the user if they end up with a situation where a they see an export named `type`,
Ah. Good point. I hadn't thought about exports. If `newName`s were used only as locals, we would be fine with a very liberal treatment for `newName`. But once we think about exporting, we do run into an issue. Come to think of it, we really shouldn't allow exporting of names created with `newName`. As Greg has pointed out, there's no reason a user should assume that a `newName "foo"` creates a variable named `foo`. If we allow exporting, then `newName`s are leaky, indeed. If we disallow exports, would that alleviate your concerns, Ben? At that point, we should really allow any (non-empty?) string as the argument for `newName`. I think Greg is spot on in suggesting that the argument to `newName` is merely a seed, not the name in question. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10599#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler