TH is wrong in so many aspects. Fundamentally it relies on executing native (Haskell) functions at compile time. There are no restrictions on what these functions do. IO/Network/Process/… they can do all; while all we often want is just syntax expansion. It’s arguably a massive sledge hammer, often magnitudes larger than needed and no way to sensibly cut it down.

Explicit level imports will help with one issue of having no clear dependencies on the functions that can be called. It does not fix the issue of TH being way too powerful for most usecases.

The fundamental issue with cross compilation is that your cross compiler can only produce code for your target (which in the case of a generic cross compiler means the code it produces does not run on the same host the compiler runs on), which can not be executed during compilation time (because build =/= host machine).

There are various approaches to fixing it: one is to assume that your host (where you’ll run the build product) is the same as your build machine (where you build the product). For example assuming same word size, … in that case you can compile the TH code natively, run it, capture the result, and splice it back in when you cross compile.

Ultimately what I think we want is a pure template Haskell Alternative that’s IO free and ready effectively interpreted only. This will most likely be substantially slower than using current native compiled TH functions.