Re: [Bug-apl] Request for feature: Back-channel interaction

[Juergen Sauermann]

Hi,

referring to a previous of your posts, I believe that there is no real 
dependency
on GNU APLs internal code when using Native functions. The dependency is 
between
emacs (in your case) and the native APL function. How the native APL 
function is
implemented is not visible or relevant to the caller of the native function.

Such a function would be tailored to one particular user; in your case
'emacs.so' ⎕FX 'EMACS' would create an APL function EMACS and only
the arguments provided to and the result returned by EMACS would be
relevant for the emacs side. Since this function is tailor made for emacs
it would only change when the emacs side has new requirements. The 
implementation
in emacs.so would be maintained together with GNU APL if something 
changes on that side.

Having that said lets look at your other topics:

Native Networking.

There is already a "networking API" in GNU APL which is used for shared 
variables (for
workspace-to-workspace communication and communication to auxiliary 
processors).
The problem with that API is that APL only reacts to signals on that 
interface when
ordered to do so (⎕SVE and friends). Otherwise signals received on that 
interface are
ignored. All-in-all I would say that use of this API (or a similar one) 
only makes things more
complicated without solving any of your current problems.

Threads / IO-channels

Maybe you need threads sooner or later. I personally don't like select() 
very much (even though
I use it at times for operations that have a timeout). A cleaner 
approach is blocking recv() or
read() in its own thread.

Of course, I would like to avoid a thread in the APL interpreter only 
for accommodating emacs.
But I see no need for that either.

Native API question

Thanks for the hint, I hadn't thought of that. Declaring extern "C" will 
not work because all
arguments are C++ classes. But I could use a extern "C" function that 
returns pointers to the
C++ functions.

/// Jürgen