Re: Generating fresh names in a source plugin

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 < simon.peytonjones@gmail.com> 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 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

-- brandon s allbery kf8nh allbery.b@gmail.com