
#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): I don't see how `newName` could possibly be made to work for this purpose. The problem is that after you splice in a Template Haskell splice (in `Convert`), it has to be fed back into the renamer. But `newName` is designed to keep the same original name (just with a different unique), so the renamer will rightly reject multiple top-level things named `con2Tag`, even if they were produced via `newName`, as there's no good way to disambiguate them. Now, you might object "but RyanGlScott, just disambiguate them by their uniques!" That's all well and good, but disambiguating by uniques is really a strategy that I can only envision working in the internals of GHC. The problem is that there are adversarial users who will want to abuse the fact that `newName` can now be used to create top-level names. For instance, what happens if a user tries this? {{{#!hs {-# LANGUAGE TemplateHaskell #-} $(splice1) -- produces top-level function named con2Tag $(splice2) -- produces top-level function named con2Tag uhOh = con2Tag }}} Here, `con2Tag` is written using surface syntax, where we don't have the power to refer to the unique of the particular `con2Tag` we want. The only sensible thing I can see doing in this situation is to error. To avoid this hornet's nest of tricky design questions, I propose we not try to retrofit the ability to create top-level names onto `newName`, but instead create a different function for this purpose. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler