Shadowing in toIface* output

[Simon Peyton Jones]

 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 <gergo at erdi.hu> 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
> <joshmeredith2008 at gmail.com> 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ő <gergo at erdi.hu> 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
> _______________________________________________
> 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/20220404/67564b68/attachment.html>