I've looked at Rainbow. Continuation passing style!
Very clever. You get first class continuations and
can optimize tail recursion.
My next thought was to write a compiler to .class files
to improve performance and optimize tail recursion.
Not sure if this road will lead to first class continuations. I'd like to do stack copying for
continuations, but
I don't yet know if that's possible in the JVM. It
might not be.
Since you've already
done continuation passing style in Rainbow, I think I'll
stick with my plan to work on a compiler next.
There is a continuation library for java at http://rifers.org/wiki/display/RIFE/Web+continuations - but it's wrapped in a web server. Apparently it does all the stack copying for you. I looked at it briefly and ran away fast. But it might be the right approach if you're compiling to bytecode, and bytecode compilation is probably the only way to make arc go fast on java.
Rainbow's continuation-passing style means arc code is not using the native java stack, which probably slows it down immensely.
I doubt a stack copy is very feasible. For one thing, it would need a potentially different implementation from JVM to JVM (and from context to context, since a JVM might optimize something in several different stack-involving ways depending on which is best at the time). Also, based on what I see at http://www.cs.princeton.edu/sip/pub/oakland98.pdf and http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf, it looks like swapping out the stack would blatantly undermine the security model of JVMs that rely on stack inspection, meaning that lots of JVMs are probably actively motivated to keep native code from getting at the wrong part of the stack. Then again, I haven't actually tried it, so maybe I'm just being pessimistic.
In any case, stack copy isn't RIFE's approach. RIFE's approach is to use a custom ClassLoader on selected classes (classes implementing a particular interface) to transform the Java bytecode into explicit continuation-passing style at runtime. Ultimately, it does nothing the Java programmer couldn't have already done by writing those particular classes in continuation-passing style to begin with. If I'm already committed to having a continuation-passing-style Arc interpreter in my Java project, I can just do my to-be-CPS-transformed code directly in Arc and be done with it.
On the opposite side of the spectrum, JauVM (http://jauvm.blogspot.com/2005/07/so-what-does-it-do.html) has an approach I think is about as comprehensive as it gets. The idea is that it's a wrapper of an existing JVM, delegating just about everything except exactly what it needs to do in order to provide first-class continuations. Unfortunately, I think JauVM does this by directly interpreting every instruction, so it's probably horribly slow.
I think the best approach for Arc-in-Java is ultimately a compromise between RIFE and JauVM: A ClassLoader that's used for everything and CPS-transforms it unless it's a specially-marked class whose programmer is prepared to manually pass continuations.
