I have not been following the details of this debate, but there is a good reason why TH doesn’t work on a cross compiler. Specifically, suppose module M imports module X, which defines a function mkD that M calls in a splice, thus $(mkD “wobble”). Currently, we compile X to X.o, and when compiling M we dynamically link X.o (and all the other libraries it relies on) into GHC so that we can call foo. Obviously X.o has to be runnable on the machine doing the compiling, so if X.o is for some other architecture that’s not going to work. There is no reason in principle why one could not compile X into X.bytecode (along with all its dependencies), where X.bytecode is architecture independent. Then X.bytecode could be interpreted on any platform. But GHC has no mechanism for doing this at all. I’ve always take the view that if you want X.bytecode, you may as well load X.hs and translate it into bytecode. A bit slower, to be sure, but maybe fast enough. But don’t forget those libraries. Anyway that’s the state of play. Have fun! Simon From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Carter Schonwald Sent: 13 June 2013 22:44 To: ghc-devs@haskell.org Subject: status of template haskell + cross compiling plans for 7.8? Hey All, Whats the story planned for template haskell + cross compiler support come ghc 7.8? I understand theres a lot of Template Haskell design underway, some of which will help support tools like Manuel's Inline-Objective-C work. Does this mean that factored out within this reorganization is a better story for cross compilation? Especially since one kill "app" for the Inline-Objective-C template haskell work would be writing IOS applications. Though I guess that also touches on the need to sort out supporting "FAT" ARM binaries too, right? This intersects with a few different large subsets of tickets, so i'm not sure if any single ticket is the right fora for this question. thanks! -Carter