Arc Forumnew | comments | leaders | submitlogin
Rainbow/Jarc on Android
2 points by jsgrahamus 2018 days ago | 4 comments
Given that Rainbow is implemented in Java, I wonder if it (or Jarc) could be run on the Android and just how that could be accomplished.

Steve



2 points by akkartik 2018 days ago | link

It's an interesting question, I don't think it's come up before.

Have you checked out semi-arc? http://arclanguage.org/submitted?id=suzuki

-----

2 points by rocketnia 2017 days ago | link

It has come up before: http://arclanguage.org/item?id=14840. I guess technically no one brought it up 25 days later at http://www.arclanguage.org/item?id=14781, but it felt like one obvious option to me.

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.

-----

3 points by gus_massa 2013 days ago | link

Symbols are garbage-collected in Racket: http://docs.racket-lang.org/reference/symbols.html

  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).

-----

1 point by rocketnia 2013 days ago | link

Awesome!

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.

-----