Running Rainbow or Jarc from a jar is easy, but there are some caveats:
- Both Rainbow and Jarc expose JVM reflection capabilities to Arc, and thus provide the Arc program with ambient authority. This is convenient for an application written in Arc, but it means we should only run Arc code the user trusts. (Rainbow might be possible to tame by nilling out some global variables, but I wouldn't count on it, and it doesn't seem in the Arc spirit.)
- Both Rainbow and Jarc intern symbols into a static field, so if someone's Arc coding style causes their program to intern lots of symbols, it may be difficult to reclaim the memory. (In fact, I wonder if Racket has the same issue.)
- Rainbow stores global variable values in the symbols themselves. Since these symbols are interned, it would be difficult to manage more than one global namespace during any given run of the JVM program, let alone to manage more than one independent Arc runtime, as a REPL program might like to do.
- Jarc has support for bytecode generation, but it probably won't work on Android. I don't think Jarc depends on bytecode generation for normal functioning, but I don't know Jarc well enough to be sure.
- Rainbow's example code, including its welder.arc text editor, makes heavy use of Swing, and I doubt that will work on Android.
Interned and unreadable symbols are only weakly held by
the internal symbol table. This weakness can never
affect the result of an eq?, eqv?, or equal? test, but a
symbol may disappear when placed into a weak box (see
Weak Boxes) used as the key in a weak hash table (see
Hash Tables), or used as an ephemeron key (see Ephemerons).
Kinda. It irks me that a value that's still arguably reachable (via 'read) could be observably lost by a weak box, weak hash table, or ephemeron. But it seems feasible to create readable-counts-as-reachable versions of these data structures on top of the built-in ones, so the built-in ones expose strictly better lower-level control.
