> > think there is at least another tag that is treated specially: `f`, > having to do with type families, from what I remember. The fact that some > tags do cause special compiler behavior makes the situation quite tricky.
If you believe that the tag has significance beyond debugging etc, you may be right -- *but can you point to any evidence? *Perhaps you can record what you learn on #26264? It may seem that a plugin author should pick a > tag that isn’t used by GHC. This is already difficult, because you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > However, what if the tags of the uniques that the plugin generates > *need* special treatment? For example, you may want to create uniques > for local variables that your plugin introduces, and GHC may use a tag > for uniques of local names that causes necessary special compiler > behavior. Once again, I know of no "special compiler behaviour" but I may be wrong. > you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > In the end, I used `grep` and my own eyes to check potentially the whole > GHC codebase for tag use. Indeed this is bad. Can you record the list of tags you discovered, and where they are born, in #26264? Thanks! Simon On Mon, 4 Aug 2025 at 23:06, Wolfgang Jeltsch <wolfg...@well-typed.com> wrote: > Am Montag, dem 04.08.2025 um 16:12 +0200 schrieb Andreas Klebinger: > > On 03/08/2025 17:25, Kai Prott wrote: > > > According to the documentation, "the payload part of the Uniques > > > allocated from this UniqSupply are guaranteed distinct wrt all other > > > supplies, regardless of their 'tag'." (Assuming the unique does not > > > overflow it's number of bits) > > > > If you read on the docs refer to an edge case in the next lines. GHC > > contains a (limited) number of fixed/"built in" uniques. GHC itself > > never creates uniques with the same tag as those fixed ones on the fly > > so there is no risk of collision. However if you explicitly use this > > tag it could happen and then compilation could go wrong. Outside of > > this that is correct. > > I think there is at least another tag that is treated specially: `f`, > having to do with type families, from what I remember. > > The fact that some tags do cause special compiler behavior makes the > situation quite tricky. It may seem that a plugin author should pick a > tag that isn’t used by GHC. This is already difficult, because you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > However, what if the tags of the uniques that the plugin generates > *need* special treatment? For example, you may want to create uniques > for local variables that your plugin introduces, and GHC may use a tag > for uniques of local names that causes necessary special compiler > behavior. > > In the end, I used `grep` and my own eyes to check potentially the whole > GHC codebase for tag use. My conclusion is that likely no specially > treated tag is used for local variables, which are what I want the > uniques for. Therefore, I probably should pick a tag that GHC surely > doesn’t use and won’t ever use. I guess I’ll go for some ASCII control > character. > > All the best, > Wolfgang > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
