Generating fresh names in a source plugin

[Andreas Klebinger]

Some slight additions to Kais message:

On 03/08/2025 17:25, Kai Prott wrote:
> Hi,
>
> what I have used In the past (and that I am fairly confident works) is 
> exactly what you say: use `uniqFromTag` or `mkSplitUniqSupply`.
>
> 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.
>
> As far as I know, end users should not get to see a unique and it 
> should not influence compilation, so the Tag is only relevant for 
> plugin/GHC devs for debugging.
Uniques influence code generation slightly, as they are part of internal 
symbol names. They should however not affect the behaviour of the 
program. This doesn't matter often, but when it does it really does.
>
> Also just curious: why do you need to construct a unique? Before the 
> GHC renamer a plugin can get away with generating essentially strings 
> that are "unique" and use them in `mkUnqual` or similar.
> Most of the time, I just generate a `RdrName` with a prefix that would 
> not be allowed in source code with an incrementing suffix that I 
> manage myself.
> I have not checked if a plugin-generated name has to be a valid 
> Haskell name nowadays. However, it worked in the past.
>
> And just for completeness if someone else stumbles across this: After 
> the GHC renamer in `CoreM`, `TcM` (and others) one can just use 
> `getUniqueM` or `getUniqueSupplyM`.
>
> Best wishes,
> Kai Prott
>
>
> On August 2, 2025 7:08:10 PM GMT+02:00, Wolfgang Jeltsch 
> <wolfgang at well-typed.com> wrote:
>
>     Hello, again! After some more digging, I came to the conclusion
>     that `uniqFromTag` is likely what I should use. However, what
>     exactly is the tag for? The note „Uniques and tags“ only says the
>     following:
>
>         The tag […] is typically used to make it easier to distinguish
>         uniques constructed by different parts of the compiler. 
>
>     Who distinguishes uniques using tags: the compiler, compiler
>     developers when reading debugging output, or end users? Does the
>     choice of tag influence the behavior of the compiler other than
>     with respect to messages? The documentation of `mkSplitUniqSupply`
>     says that the tag “is mostly cosmetic”. If it is only *mostly*
>     cosmetic, what aspects of it are not cosmetic? In the end, how do
>     I choose a tag for uniques generated by a plugin? Is the choice
>     essentially irrelevant? Do I have to prevent clashes with tags
>     used by GHC or other plugins? Looking forward to insights. 🙂 All
>     the best, Wolfgang Am Samstag, dem 02.08.2025 um 16:16 +0300
>     schrieb Wolfgang Jeltsch:
>
>         Hello! I want to generate AST fragments in a source plugin,
>         and for this I need to generate fresh (local) names. My
>         current approach is to use `mkSystemName`, but it, like many
>         of the other name-generating operations, needs a value of type
>         `Unique`. How can I generate such values? It seems that the
>         `Hsc` monad doesn’t carry a value of type `UniqueSupply` with
>         it. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250804/acf28783/attachment.html>