| The issue is this: | | how can one compile a program that uses TH | so that the resulting executable is profiled | | I'll call | C-code is code that runs at compile time | R-code is code that runs at runtime | | We aren't trying to profile C-code, only R-code. Further ruminations, following discussion with Simon M. Assume that a module M contains a mixture of C-code and R-code (which in general it can). Compile it both ways: ghc -c M.hs (generates M.o non-profiled, M.hi) ghc -c -prof -O M.hs -o C.p_o (generates M.p_o profiled, M.hi again) Now suppose module A is like this: module A where { import M( f ) $(f 3) h x = f x } A contains only R-code, so it need not be compiled without -prof. When we say ghc -c -prof -O A.hs GHC will load M.hi, then dynamically link the non-profiled M.o, and run it. Later you link A.o and M.p_o, and all should be well. NOTE that M.hi serves to describe both M.o and M.p_o. That's ok, because all the TH part needs (when typechecking $(f 3)) is the type of f, and that's the same in both M.o and M.p_o. It's important to compile M.hs with -prof *second* so that the profiled .hi file is the one that survives. If you are optimising, the unfolding should be the ones for R-code, not C-code. One other issue is this. TH/GHCi don't currently call the module-initialisation procedure after dynamically linking a module. This is really a bug. The module-init procedure registers foreign exports, so presumably that does not currently work in GHCi. The dynamic linker should really run the init procedures of the (root) modules it loads. Simon