[Haskell-cafe] Haskell for Gingerbread

austin seipp as at hacks.yi.org
Tue Dec 28 21:16:32 CET 2010

There was work ongoing for an ARM port of GHC. See here:


Also see:


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:


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
<haskell at list.mightyreason.com> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


More information about the Haskell-Cafe mailing list