<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">
So does that mean Tidy produces unique `occNameFS`s, and then `Prep`<br>
breaks them? <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Tidy does not produce unique OccNames.  Rather, it avoids <i>shadowing</i>, so that if you delete all the uniques and print out the program (which is precisely what happens in an .hi file) you'll still get something sensible.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I'm not sure whether or not Prep maintains this invariant.  There is no particular reason it should.  It might, but it is not (currently) a goal.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 2 Apr 2022 at 04:35, Gergő Érdi <<a href="mailto:gergo@erdi.hu">gergo@erdi.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So does that mean Tidy produces unique `occNameFS`s, and then `Prep`<br>
breaks them?<br>
<br>
On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith<br>
<<a href="mailto:joshmeredith2008@gmail.com" target="_blank">joshmeredith2008@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I encountered this when we used that for Plutus. I'll have to dig up the details, but IIRC `toIfaceExpr` expects GHC to have already tidied the output, which deals with this issue of overlapping variable names.<br>
><br>
> Cheers,<br>
> Josh<br>
><br>
> On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő <<a href="mailto:gergo@erdi.hu" target="_blank">gergo@erdi.hu</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I'm trying to save (Prep'd) Core bindings right next to the serialized<br>
>> `ModIface` (so basically `put_`ing them into the same bytestream, after the<br>
>> `ModIface`), and that's exactly what the functions in `GHC.CoreToIface`<br>
>> seem to be for, so I expected it to Just Work. However, I noticed that I<br>
>> very frequently get problems with shadowing. For example, Core that looks<br>
>> like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which is<br>
>> disastrous since these locally bound `Var`s are represented as just their<br>
>> `getOccFS` (i.e. the `FastString` `"v"`).<br>
>><br>
>> But this can't be right: if `toIfaceExpr` &c. would fail this blatently,<br>
>> then the unfoldings couldn't be saved & restored, which is something GHC<br>
>> itself does as part of normal `.hi` file handling. So clearly I must be<br>
>> doing something wrong.<br>
>><br>
>> So I guess my question could be, what could be causing `toIfaceExpr` (a<br>
>> pure function!) to behave this way for my Cores? But then, if I look at<br>
>> the implementation of `toIface*`, I can see that it really doesn't do<br>
>> anything smarter than just storing `getOccFS` in the interface (no<br>
>> uniques in sight)-- so maybe my *real* question is, what is GHC itself<br>
>> doing so that it doesn't have this same problem?<br>
>><br>
>> Thanks,<br>
>>         Gergo<br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>