Hello again, and yet another followup to myself...
After having slept on this, I had a few more thoughts around this stuff that I would like to share with you:
Native networking?
I realised that there is yet another potential solution to the communication with an external agent that I never considered. There would be no need to depend on the native API if there was a native networking API in GNU APL. Not only would such API be useful for other things, but then the entire APL-side implementation can be implement in APL and loaded into the interpreter on startup, without any need for native C code.
I'd be willing to whip up a test implementation for this, if you're interested.
Threads or I/O channels
No matter what approach I will choose for the Emacs communication, there is still the problem of being able to listen on a network socket while at the same time waiting for input on the commandline.
Usually one resorts to either threads or some kind of select() or poll() like mechanism for this. What is your suggestion here?
Native API questions
In the current implementation, you're relying on a certain C++ name mangling scheme (the one use din GCC I presume). This will not work on any other compiler, for example the Sun C++ compiler suite. It will also not work on other operating systems.
If at all possible, porting would be easier if the call into native code was done through symbols that are declared extern "C". This will remove dependency on a certain C++ ABI (which is not standardised, unfortunately).
Regards,
Elias