Generating fresh names in a source plugin

[Simon Peyton Jones]

>
>  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 <wolfgang at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250804/4612bf23/attachment.html>