Congratulations! Is this going to become a full arc interpreter? The stated goals include compatibility with arc, but jarc is missing tail-call optimisation and first-class continuations. Implementing these in java turned my hair gray overnight and required a complete rethink of rainbow.
Competition for rainbow ... re-open project ... I will just have to stop sleeping or something ...
Competition can be good, but I'm open to cooperation. You can send email to my jazzdev gmail account. I've avoided looking at rainbow until I got Jarc released. Now I'm curious to see what you've done.
Rainbow is 2x faster than Jarc, and first class continuations are impressive!
I used ccc in an arc parser I wrote (it's at lib/parser.arc in anarki) ... I confess however that the choice of using ccc was driven more by the desire to experience this exotic construct than by the problem itself (as well as needing something to test rainbow's ccc with). The whole thing could be rewritten more simply.
That's a good example because in this case ccc in only used within the library. Thus an implementation option is to support ccc within a library while giving up something else while running inside the library (speed, or interoperability with Java classes, etc.) that makes to feasible or easy to support ccc inside the library. (After all worst case is that you write an Arc interpreter in which it is easy to support full ccc but it runs 20 times slower). Outside you don't support full continuations, but you have your regular Java Arc implementation (which runs really fast etc.)
ccc is also used by the 'point macro in arc.arc - but it's only used as an escape continuation, which is only jumping back up the stack, not copying it, so can be implemented very easily in java without introducing performance issues.
'point is also the only place I could find ccc used in the original arc distribution.
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.
