Generating fresh names in a source plugin

[Brandon Allbery]

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 at 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 <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
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250804/a4dded0e/attachment.html>