Generating fresh names in a source plugin

[Wolfgang Jeltsch]

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