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.
