There's supposed to be one already, IIRC. And indeed, there is `Note [Uniques for wired-in prelude things and known tags]` in compiler/GHC/Builtin/Uniques.hs. If you've found more, they should probably be added there.
On Mon, Aug 4, 2025 at 6:19 PM Simon Peyton Jones < [email protected]> wrote: > 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 <[email protected]> > 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 >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh [email protected]
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
