Re: Shadowing in toIface* output
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
> 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` 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
initIface* usage in plugins
Hi, I'm trying to use initIfaceLoad and initIfaceLcl to lookup core `Name`s within a plugin. My understanding is that functions such as `lookupIfaceTop` are used for this, but I'm running into an issue that I suspect is caused by some `Name`s being inappropriate for this function, so they fail with the error `Iface id out of scope: ...`. Is there a robust way to select which `Name` lookup function to use based on a core binding/expression? Thanks, Josh ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Iface loading type reflection module bindings
Yes, based on Michael's reasoning in https://gitlab.haskell.org/ghc/ghc/-/wikis/Core-interface-section, I want to round-trip the entire ModGuts, and this part of the mg_binds is giving me trouble. On Mon, 18 May 2020 at 03:05, Matthew Pickering wrote: > So we are clear here you are trying to store additional core bindings > other than the ones stored normally in the interface files? > > It sounds like to me you might need to use `forkM` to make your custom > loading lazier. > > On Sun, May 17, 2020 at 5:55 PM Josh Meredith > wrote: > > > > Hi, > > > > In attempting to implement an extensible interface field for Core > bindings based > > on my previous interfaces patch, I've run into problems with > deserialising the > > special type reflection `$trModule` bindings generated by > `GHC.Tc.Instance.Typeable.mkTypeableBinds`. > > These bindings are then stored in the `ModGuts.mg_binds` along with the > real exported > > top-level bindings of the module. > > > > Specifically, attempting to load the iface right-hand side expressions > with > > `tcIfaceExpr` results in the error "Iface id out of scope" from > `GHC.Iface.Env.tcIfaceLclId`. > > My understanding is that this may be because the binding is attempting > to look > > itself up within the interface loading environment, without being bound > yet - > > though it's unclear to me whether this is the correct behaviour for > these special > > type reflection bindings, or if there's some special treatment that > should be > > instead applied to load these. > > > > Any advice on how I should proceed would be greatly appreciated. > > > > Cheers, > > Josh > > ___ > > 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
Iface loading type reflection module bindings
Hi, In attempting to implement an extensible interface field for Core bindings based on my previous interfaces patch, I've run into problems with deserialising the special type reflection `$trModule` bindings generated by `GHC.Tc.Instance.Typeable.mkTypeableBinds`. These bindings are then stored in the `ModGuts.mg_binds` along with the real exported top-level bindings of the module. Specifically, attempting to load the iface right-hand side expressions with `tcIfaceExpr` results in the error "Iface id out of scope" from `GHC.Iface.Env.tcIfaceLclId`. My understanding is that this may be because the binding is attempting to look itself up within the interface loading environment, without being bound yet - though it's unclear to me whether this is the correct behaviour for these special type reflection bindings, or if there's some special treatment that should be instead applied to load these. Any advice on how I should proceed would be greatly appreciated. Cheers, Josh ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
