#13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: 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 goldfire): `newName` is intended for producing local names only, not anything top- level. I'm not surprised that it runs into trouble when you're using it at top-level. In a terrible horrible no-good workaround, my `th-desugar` library exports {{{ -- | Like newName, but even more unique (unique across different splices), -- and with unique @nameBase@s. Precondition: the string is a valid Haskell -- alphanumeric identifier (could be upper- or lower-case). newUniqueName :: Quasi q => String -> q Name newUniqueName str = do n <- qNewName str qNewName $ show n }}} This should fix your problem but is a sad, sad thing. The whole `newName` facility needs an update. Waiting for copious free time to do so! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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've given this some further thought, and my belief is that `newName` really can't be made to work well with top-level identifier names. After all, if you have two top-level foreign imports with the name `makeFun` and you try invoking `makeFun` somewhere, how is GHC supposed to tell the two `makeFun`s apart, even with different uniques? `newName` just doesn't work for that purpose. Now perhaps you don't care about having a foreign import with the exact name `makeFun`—you just want a unique top-level name that sorta kinda looks like `makeFun` (perhaps, say, `makeFun_4j121c4`). I think there is a valid need for such functionality, and in fact, I think Richard's `newUniqueName` provides more or less a blueprint for how one might actually implement it in GHC. I propose adapting the implementation to create a `newGlobalName` function for this purpose. Moreover, I propose we note the fact that `newName` is insufficient for top-level names in its Haddocks, and point to `newGlobalName` as an example of how you should do it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 simonpj): I'm not convinced yet. Expanding the API for TH is ok, but it complicates the user model. Let's see. This conversation concerns top-level declarations. I can see two use-cases * Functions or data types that are used locally (in some other function or data type), but not really exported. * Functions or data types that are exported. For the former, it's in implementation shortcoming that `newName` does not work (e.g. comment:2). For the latter, for it to be useful importing module needs to know the name, so exporting (say) `makeFun_4j121c4` and `makeFun_4j12137` is not helpful. So maybe the latter is a non-use-case. If it's just the former I think we should be able to make it "just work". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 also agree that `newName`s should not be exportable! Moreover, I don't think you really should be exporting `newGlobalName`s either—but that doesn't mean it's a non-use-case! Quite often in Template Haskell code you'll want to define top-level functions that are used across other functions. For example, in my [http://hackage.haskell.org/package /deriving-compat-0.3.6/docs/Data-Enum-Deriving.html deriving-compat] library, I've found myself wanting to define a function: {{{#!hs con2tagFoo :: Foo -> Int# }}} Like what happens when you derive `Enum` in GHC today, only in Template Haskell. This needs to be a top-level identifier, however, since `con2tag` functions also get used across multiple `Enum` methods, so I need to ensure that this `con2TagFoo` name is globally unique. However, it certainly doesn't need to be exported. Currently, the only way to do this is with something like `newUniqueName` from comment:2, which isn't robust against things like infix names. I imagine tim-m89's use case would also be served by `newGlobalName`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#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): Replying to [comment:10 simonpj]:

I think the `RdrName`s generated by `newName` are `Exact`, right? Not `Unqual`. Maybe the renamer should not complain about collisions between `Exact` top-level names.

No, they are unqualified. See https://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): My apologies, I was mistakenly under the impression that `NameU`s weren't exact. As for the idea of having GHC accept collisions between two `Exact` names with the same `nameBase` but different uniques... the idea still makes me a little bit queasy. I can think of a couple of unfortunate consequences of permitting this: 1. The fact that the program in comment:9 would still be ambiguous. Allowing `newName` to create valid top-level names means that you can effectively only use them from Template Haskell code in the event you use `newName` to create multiple copies of the same name. If you did such a thing, any attempt to use one copy of the name would result in ambiguity. This means that exporting them, importing them, using them in user- written source code, etc. is a no-go. This really feels like the wrong design to me—we shouldn't be encouraging the use of such a fragile mechanism. 2. How will Haddock render two top-level names with the same `nameBase` generated with two different calls to `newName`? Haddock would pretty much have to render the same function names twice, which is bound to cause confusion for readers. On the other hand `newGlobalName` would not be subject to these flaws. Because names produced by `newGlobalName` are truly unique (due to the suffix attached to them), no problems emerge from calling `newGlobalName` twice with the same `nameBase`. (I'm aware that programs like comment:9 aren't the intended //purpose// of `newGlobalName`, but it would be nice to rule out such tomfoolery by construction.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Hm. Provided there's a robust way to comprehensively rule out //all// occurrences of duplicate names with different uniques, I think I could support this idea. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 simonpj): Yes, that's what I've been trying to say too. If you want a name you can mention outside TH, use `mkName :: String -> Name`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13054#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler