[Haskell-cafe] Status of Haskell on Android? Possible ideas to make this happen?

Alp Mestanogullari alpmestan at gmail.com
Thu Jun 7 12:59:41 CEST 2012


Hi Cafe!

I know, this topic comes back on the list from time to time. I know, there
probably isn't anything new since the last time it was asked here, on
reddit or on SO.
However, I remember seeing that iPwn Studios were thinking about getting
GHC to build applications for android, in addition to their ghc-iphone
project. Is this correct? Is there anything new on that front? Is anyone
else working/thinking-to-work on this?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120607/529dff9c/attachment.htm>


More information about the Haskell-Cafe mailing list