So does that mean Tidy produces unique `occNameFS`s, and then `Prep` breaks them? Tidy does not produce unique OccNames. Rather, it avoids *shadowing*, 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. 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. Simon On Sat, 2 Apr 2022 at 04:35, Gergő Érdi wrote:

So does that mean Tidy produces unique `occNameFS`s, and then `Prep` breaks them?

On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith wrote:

...

Hi,

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.

...

Cheers, Josh

On Sat, 2 Apr 2022 at 01:26, É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

...

...

`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

the 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@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

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 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@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