<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I have opened #21333 to track this poor documentation of tidyProgram.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Zubin may be right about implicit bindings (as I remark in the ticket) but if so we should fix that so that the no-shadowing invariant does hold. I don't want clients to have to work around this, as Zubin implies HLS is doing.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">If it doesn't, can someone add a repo case?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Would someone like to put up an MR for #21333?  -- I have made a stab in the ticket itself.<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 Fri, 1 Apr 2022 at 15:40, Zubin Duggal <<a href="mailto:zubin@well-typed.com">zubin@well-typed.com</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">I suspect these are implicit bindings that you will need to filter out<br>
and regenerate from the tycons.<br>
<br>
You might find this HLS PR instructive as it implements something quite similar<br>
to what you seem to want: <a href="https://github.com/haskell/haskell-language-server/pull/2813" rel="noreferrer" target="_blank">https://github.com/haskell/haskell-language-server/pull/2813</a><br>
<br>
It is also relevant to question about OtherCon and unfoldings you asked<br>
earlier, as it implements a workaround for ignoring this information<br>
during testing of the generated core. Fortunately we don't need to care<br>
about this as we only use the serialized core to generate bytecode,<br>
where this information is not relevant.<br>
<br>
I believe the only reason OtherCon isn't zapped by corePrep in GHC is<br>
because core lint tends to complain if it is.<br>
<br>
Cheers,<br>
Zubin.<br>
<br>
On 22/04/01 22:25, ÉRDI Gergő wrote:<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, <br>
>after the `ModIface`), and that's exactly what the functions in <br>
>`GHC.CoreToIface` seem to be for, so I expected it to Just Work. <br>
>However, I noticed that I very frequently get problems with shadowing. <br>
>For example, Core that looks like `\v{u1} v{u2} -> v{u1}` would get <br>
>translated to `\v v -> v`, which is disastrous since these locally <br>
>bound `Var`s are represented as just their `getOccFS` (i.e. the <br>
>`FastString` `"v"`).<br>
><br>
>But this can't be right: if `toIfaceExpr` &c. would fail this <br>
>blatently, then the unfoldings couldn't be saved & restored, which is <br>
>something GHC itself does as part of normal `.hi` file handling. So <br>
>clearly I must be doing something wrong.<br>
><br>
>So I guess my question could be, what could be causing `toIfaceExpr` <br>
>(a pure function!) to behave this way for my Cores? But then, if I <br>
>look at the implementation of `toIface*`, I can see that it really <br>
>doesn't do anything smarter than just storing `getOccFS` in the <br>
>interface (no uniques in sight)-- so maybe my *real* question is, what <br>
>is GHC itself 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>
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>