Wouldn't it be simpler just to fork from 4.2? Making immutable pairs not-really-immutable shouldn't actually break any existing PLT-based code, since that code won't modify them. ^_-
It might break some low-level optimizations in PLT Scheme itself (which could be fixed in the forked version), it might break compatibility with other projects that dig into the PLT code, and it might annoy some library writers who really didn't want careless users to shoot themselves in the feet or expose security holes, but that's all the trouble I can think of offhand.
Breaking the PLT Scheme optimizer by mutating pairs it thinks are going to be immutable and then going in and figuring out which optimizations to fix doesn't sound very simple to me... but, assuming that it was easy to do, what does starting from 4.2 do for us?
I guess I just see "Take the newest MzScheme and implement not-so-immutable conses again" as a conceptually easier task than "Take the fork and implement feature A and feature B as inspired by the newest MzScheme." Of course, the more objections we have to MzScheme changes, and the more features of our own we want to include, the harder this becomes.
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.
