There was work ongoing for an ARM port of GHC. See here: http://tommd.wordpress.com/2010/01/19/ghc-on-arm/ Also see: http://alpheccar.org/en/posts/show/94 Alpheccar's build uses the work of Stephen Blackheath to cross compile, which originated in the GHC-iPhone project, based on ghc 6.10.2 I believe. They are both based on the unregistered C backend, i.e. using the -fvia-C backend. None of this work has been accepted upstream as of me typing this, as far as I know. Certainly the large majority of Stephen's work is not in GHC (in particular things like the POOLSIZE wrapper, which is a workaround for not being able to generate code at runtime via libffi, because the iPhone doesn't allow it. I don't think Android has the same restrictions, here.) There are some plans underway for adding cross compilation support to the GHC build system, see here: http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation In particular this avoids the need for non-standard and painful build setups like alpheccar went through, or the peculiar dance that e.g. HalVM has to go through to cross compile GHC for Xen. Overwhelmingly, I would say focusing efforts on GHC is the way to go. JHC is fiddly (and still fails badly on some simple programs,) ditto for LHC which is highly experimental and not quite as portable. nhc98 would probably be a good baseline, but the lack of language extensions and support from the community probably means you're not going to get a lot to work with it. yhc seems unmaintained. GHC also generates better code than pretty much anything else, too (except when JHC manages to actually work.) GHC is what everybody uses and knows, so it seems best to focus efforts here. Getting GHC to actually support cross compilation in the build system is IMO probably the biggest thing that needs to be done, before any sort of registered ARM port, or adding support for android to the runtime (if that would even be necessary, I have not looked at the Android Gingerbread NDK notes - it may be possible to just have a library that takes care of interfacing with the NDK.) I say this because I think GHC being cross compilable is ultimately a much greater goal than just a port to work on Android/ARM (even debian has had unregistered arm/armel GHC builds for a while, IIRC) and would make using GHC with more exotic toolchains much, much easier (android included.) Until then, your only hope is porting the unregistered compiler, which can be quite frustrating and delicate (and doesn't always work - see the GHC wiki page on Porting.) Perhaps we should be paging Mr. Simon Marlow in here, since he can probably give a better and more concrete answer. On Tue, Dec 28, 2010 at 1:27 PM, Chris Kuklewicz wrote:

Hi folks,

 I have been looking at developing for my Android phone which is running Gingerbread (Android version 2.3).  The important thing about the official development kit is this:

The new native development kit (C/C++ cross compiler for ARM) is that the you can create android applications from pure C without using the Dalvik/Java virtual machine at all.  The thinking behind this was probably for game developers to be able to avoid their VM.

So all that might be needed is a Haskell compiler with a C-backend that emits ARM-compatible code and an initially minimal android runtime. Implementing to the new "native_activity.h" allow for the usual application life-cycle: onStart, onPause, onResume, onStop...

Some options I have not had a chance to look into:

1) GHC arm port and -via-C 2) jhc (and lhc) generated C 3) port nhc98 4) port yhc bytecode runtime

Does anyone know who else is thinking along any of these lines?  Are there 5th or 6th routes to take?

Cheers,  Chris Kuklewicz

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards, Austin