static code generation and open Accs

[Manuel M T Chakravarty]

Steve,

> One small detail is that on our cross-compiler, TH doesn't work.  This 
> to do with how I compiled it, but it is possible that GHC might need 
> some persuading before it will run Template Haskell when compiled as a 
> cross compiler.  We should use TH in the general case, but I can bypass 
> it for my application.

TH for cross-compiling is probably difficult to realise (it would have to generate two version of all code, because it might be run at either compile-time or runtime).  But as you say, you can always bypass it.  BTW, the CUDA backend does use TH at the moment (but in a non-essential manner, it is just a convenience).

> My priority is completing the game, so some time soon I am going to 
> decide whether to contribute a C back end to accelerate, and then use 
> that, or hand-code the C.  I know which one would be more fun, but I 
> have to be hard-nosed about it.  Time is not the only consideration. 
> Code quality is also important, so accelerate is very attractive indeed.

Sure, your product has to take precedence.  If you decide to use Accelerate, it is probably easiest if duplicate the CUDA backend and then modify it to generate plain C code (and take out the dependency on TH).

> Later I may add support for VecLib like we discussed, but I'd start with 
> plain C.
> 
> If and when I come to it, I feel like I've got enough background now to 
> start ripping into it and sending you patches, with plenty of questions 
> about the details of course, so thank you very much for your email.

Good luck and please let us know if we can help.

Manuel