FAQ for lang.
Why not use a standard data interchange format like JSON or RPC? Then you could plug in any client / server combination that you wanted.
This is an example of a midlayer mistake.
Certainly Arc should be able to easily talk JSON or use an RPC server. But to constrain an interaction which isn’t JSON or RPC into a JSON or RPC mold leads to unnecessary work and complexity.
For example, we may want to end up with an Arc symbol on the Arc side. If the Lang program is generating an Arc expression, returning an Arc symbol is easy. Just return an Arc symbol.
If we’re using JSON or RPC, now we need to construct some mechanism to represent Arc symbols. Which ends up encoding an Arc expression in the other format.
Life is much easier when we have libraries that we can use when they are useful, instead of frameworks that we have to squash our code to fit into. When talking to a JSON or RPC service, talk JSON or RPC. When talking to an Arc process, send an Arc expression. Then it’s easy and straightforward to get the Arc expression you want.
Why HTTP?
See Why HTTP?
In particular, a common way to get two languages to be able to call each other is to get them both working in the same runtime, so that they’re both running in the same process. There are many examples: for example, Jython and Rainbow are implementations of Python and Arc on top of the Java runtime. These are often convenient, and enable some things that aren’t possible when the two languages are running in separate processes.
However, running both languages in the same runtime means that one language or the other isn’t running in its standard runtime. So there will always be libraries that haven’t been ported over yet. There are Python libraries that haven’t been ported to Jython, and Arc libraries that haven’t been ported to Rainbow. So being able to run the languages in separate processes in their standard runtimes is also useful, since you can always use a library written for the standard language.
The Lang code generated by Arc is eval’ed on the Lang server, why don’t you have the return value generated by the Lang code eval’ed back in Arc instead of simply read?
Gosh, I don’t know.
Note that if you do want to have the return value eval’ed in Arc, you can easily do that at compile time with a macro or at run time with eval.