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