Consider avoiding the `unsafeRunTcM` trick
michaelpj opened this issue · comments
... or perhaps provide a flag to turn it off (at the cost of worse error reporting).
I don't have a smoking gun, but I suspect this is related to whatever was causing my issues in #111, and I have word from a GHC expert that this will definitely not work when cross-compiling/using the external interpreter, which is a thing that people want to do (and it'll be fairly obscure to discover the problem).
There are two use cases for unsafeRunTcM in the PyF codebase.
- One is for bettor localisation of error reporting. It replaces the template haskell
reportErrorhttps://hackage.haskell.org/package/template-haskell-2.19.0.0/docs/Language-Haskell-TH.html#v:reportError function by just adding the precise localisation of the error. I have NO idea why this could generate any failure in a different context, because theunsafeRunTcMhere literally call the same code asreportError, but replaces one argument (the localisation). Note also that this code path is only used when an error happen, so it may not be a problem if this fails in a cross compilation context. - One is to detect the missing variable names, and is the error you observe in #111. This usage of
unsafeRunTcMis more convoluted and may be the reason why it fails. I may revert this recent change and/or introduce a flag as you suggest. This codepath is used everywhere, so indeed it will be used during your cross compilation.
@michaelpj I've tested the problem in your codebase based on what you describe in IntersectMBO/plutus#4862 and indeed, the use of unsafeRunTcM was responsible for the problem.
I'm refactoring to remove the usage of unsafeRunTcM in the "normal" path, leaving the only use case for the "error" path.
See #117
Wonderful, thank you! I think this should also work with cross-compilation since the error case won't be hit in the normal case, and if there's an error then users should be able to detect that in normal compilation 👍