Aside from these questions, I'm wondering about the "easiest" way to get a ghc-android compiler up and running. I have found a few things, but they all look really, really painful and cumbersome, like http://stackoverflow.com/a/5152910/193424 or http://stackoverflow.com/a/7301024/193424 .

Recently, I heard about Renderscript: http://developer.android.com/guide/topics/renderscript/index.html

Of course, we could write a binding or some kind of EDSL à-la Atom to have some funny apps/games running on Android by generating Renderscript code under the hood. However, something in the "Renderscript Runtime Layer" section caught my attention:

> You define your Renderscript code in .rs and .rsh files in the src/ directory of your Android project. The code is compiled to intermediate bytecode by the llvm compiler

> that runs as part of an Android build. When your application runs on a device, the bytecode is then compiled (just-in-time) to machine code by another llvm compiler that

> resides on the device. The machine code is optimized for the device and also cached, so subsequent uses of the Renderscript enabled application does not recompile the

> bytecode.

But hey, GHC *does* have an LLVM backend! So can't we somehow break that chain of compilers so that we can plug GHC's LLVM codegen on top of it and then use their llvm-on-the-device thing? I know I am skipping over many, many technical details like how we could have an analog to their "reflected layer" on the java side but I would really be interested in hearing your opinions/objections/thoughts on this.

Alp Mestanogullari