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