[jhc] what to work on next?

[John Meacham]

On Tue, Jun 23, 2009 at 09:44:50PM -0400, Rick R wrote:
> I don't know if you follow haskell cafe, but there was a lot of buzz over a
> new iPhone target. for GHC. It apparently took some hacks of the ghc source
> to get it into that state. 

Yeah, that is part of the reason I pushed out the new release, since it
makes compiling for targets like the iPhone a lot simpler. I was using
jhc to write haskell programs for the iPhone back with my Gen1 phone
before the AppStore existed. (jailbroken of course)

> There is a lot of interest in being able to
> easily target other platforms, if it supported JVM that would be huge.
> Compiling to C/Native for the arm platform would be pretty great as well.

Compiling to the ARM works just fine via gcc right now. I have tested
MIPS, ARM, and x86, but I don't think there is any reason jhc won't work
with any back end that gcc supports. 

I would like to do a JVM target, but there are a couple things holding
me back. The first is that a clear mapping from Grin to JVM isn't clear.
jvm doesn't support some vital things such as structures (without the
class overhead) and unsigned arithmetic (this may not be true anymore,
does anyone know?)

The other thing is library support, We would need to rewrite the Prelude
functions to refer to JVM primitives rather than 'fread' 'fopen' and
whatnot. I don't think the task is difficult, but it's time consuming
and I don't know enough about the JVM api to get started. A syntax for
'foreign' declarations importing java primitives would also be needed. I
have a syntax for dotnet primitives, perhaps it can be re-used pretty
straightforwardly for java. In any case, I think a JVM or .NET back end
would be quite doable, but it is not something I can do without
help/support from someone fluent in the given VM and its APIs.


> I'm sorry to hear about the region based GC. It would be neat if it worked.
> As an idea, it seems like the holy grail of GC. But everyone I've talked to
> says that it seems easy at 1st, but bucketing objects into regions seems to
> frequently place too much into the global pool.


Well, it is not lost work. as any effort I put into static analysis
(which I lump all compile-time garbage reduction techniques) puts less
of a strain on the run-time garbage collector and improves cache
efficiency. No doubt some hybrid will evolve. Region inference can tell
me what can be allocated on the stack for instance, and that is a big
win even if I don't have general regions.


> Timber sports a nice, incremental garbage collector that can be made to
> guarantee sub millisecond response times. Perhaps one could take some
> inspiration from it as a replacement for the current GC.

I'll look into it, an issue is that I am looking for a GC I can use with
the gcc backend. Other backends (such as cmm or jvm) come with their own
garbage collectors, and although a native code generator would be neat,
I wouldn't want to rely on one. In fact, rather than write a native code
generator, I would likely want to write a standalone c-- compiler that I
can bundle with jhc. In the end, grin is close enough to c-- that I
don't think I lose anything in the translation.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/