Shadowing in toIface* output

[Simon Peyton Jones]

I have opened #21333 to track this poor documentation of tidyProgram.

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.

If it doesn't, can someone add a repo case?

Would someone like to put up an MR for #21333?  -- I have made a stab in
the ticket itself.

Simon

On Fri, 1 Apr 2022 at 15:40, Zubin Duggal <zubin at well-typed.com> wrote:

> I suspect these are implicit bindings that you will need to filter out
> and regenerate from the tycons.
>
> You might find this HLS PR instructive as it implements something quite
> similar
> to what you seem to want:
> https://github.com/haskell/haskell-language-server/pull/2813
>
> It is also relevant to question about OtherCon and unfoldings you asked
> earlier, as it implements a workaround for ignoring this information
> during testing of the generated core. Fortunately we don't need to care
> about this as we only use the serialized core to generate bytecode,
> where this information is not relevant.
>
> I believe the only reason OtherCon isn't zapped by corePrep in GHC is
> because core lint tends to complain if it is.
>
> Cheers,
> Zubin.
>
> On 22/04/01 22:25, ÉRDI Gergő wrote:
> >Hi,
> >
> >I'm trying to save (Prep'd) Core bindings right next to the serialized
> >`ModIface` (so basically `put_`ing them into the same bytestream,
> >after the `ModIface`), and that's exactly what the functions in
> >`GHC.CoreToIface` seem to be for, so I expected it to Just Work.
> >However, I noticed that I very frequently get problems with shadowing.
> >For example, Core that looks like `\v{u1} v{u2} -> v{u1}` would get
> >translated to `\v v -> v`, which is disastrous since these locally
> >bound `Var`s are represented as just their `getOccFS` (i.e. the
> >`FastString` `"v"`).
> >
> >But this can't be right: if `toIfaceExpr` &c. would fail this
> >blatently, then the unfoldings couldn't be saved & restored, which is
> >something GHC itself does as part of normal `.hi` file handling. So
> >clearly I must be doing something wrong.
> >
> >So I guess my question could be, what could be causing `toIfaceExpr`
> >(a pure function!) to behave this way for my Cores? But then, if I
> >look at the implementation of `toIface*`, I can see that it really
> >doesn't do anything smarter than just storing `getOccFS` in the
> >interface (no uniques in sight)-- so maybe my *real* question is, what
> >is GHC itself doing so that it doesn't have this same problem?
> >
> >Thanks,
> >       Gergo
> >_______________________________________________
> >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/20220401/e86d9009/attachment.html>