<div dir="ltr"><div>I'm aware that unique names are unique in a GHC invocation.</div><div>But my statements sill holds. <br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 7:20 PM Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Csaba Hruska <<a href="mailto:csaba.hruska@gmail.com" target="_blank">csaba.hruska@gmail.com</a>> writes:<br>
<br>
> Hi Ben,<br>
><br>
> I thought that it is possible to rely on unique values *in case of non<br>
> exported Ids* because they are local to a specific module and can not<br>
> appear in expressions in other modules because they are not exported.<br>
> Do I miss something?<br>
><br>
Uniques should be treated as being non-reproducible across compiler<br>
sessions.<br>
<br>
To make this more concrete: if GHC compiles the same module twice it<br>
will not necessarily assign the same uniques to the module's Names.<br>
Uniques are derived from local UniqSupplies conjured up at a variety of<br>
points in the compilation pipeline (search from mkSplitUniqSupply).<br>
<br>
These supplies are themselves derived from an impure global counter (see<br>
compiler/cbits/genSym.c). The state of this counter (and consequently<br>
the uniques derived from it) should be treated as being entirely<br>
unpredictable.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div>