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
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 <joshmeredith2008@gmail.com> 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
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 <matthewtpickering@gmail.com> 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 <joshmeredith2008@gmail.com> 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
participants (2)
-
Josh Meredith -
Matthew Pickering