Parallel sessions in Dyalog APL

Question

At least one of the single-letter languages (certainly q) has a facility for interprocess communication, a kind of parallel execution of longer-running processes on multiple computers. These sessions could be on the same computer or on a server on a different continent.

With q, I would simply start a server to listen to a particular port, something like q -p 8510, then access it from another q session or other software. Impressively easy.

I remember, in the very distant past, using a mainframe APL system with Shared Variables where I could share a variable with another user. This may have been IBM APL.SV. I didn't think much of that at the time, but today, decades later, Shared Variables sounds like the basis for parallel sessions. Share a variable with another computer.

How could or would I do this today with Dyalog APL, or any other APL, where I could

• invoke an APL session on another physical computer

• send it a command or an expression

• receive a result

• potentially do this in parallel on many other computers

Answer 1

In fact, "Old Fashioned" Shared Variables are still supported in Dyalog APL under Microsoft Windows via the DDE protocol, but they are considered deprecated.

Recent versions of Dyalog APL support parallel or asynchronous execution through isolates, which are separate processes that appear as extensions of the active workspace. Any expression executed within an isolate immediately returns a future. Futures can be passed as arguments to functions, and be manipulated by structural primitives without blocking; if they are passed to a primitive function which needs to know the value they will automatically block until the computation of the result is completed.

The documentation for futures and isolates is online, and there are a number of videos online - for example there is the talk where they were introduced at Dyalog'14 here:

Parallel Programming with Dyalog 14.0 on YouTube

In version 17.0 we will be including support for the APLSSH class, which will make it straightforward to launch isolates on remote machines.

Finally, if you want to communicate between APL processes which are already running, the TCP library "Conga" (which is also included in a standard Dyalog installation) allows you to pass APL arrays between processes using TCP/IP, even if the processes are running on different machine architectures. Documentation for Conga is also online.

Answer 2

Nice question! In a recent Webinar Dyalog's CXO illustrated one way to do this (handling how to easily setup Docker Containers running your code on aws or elsewhere). Also Isolates might be useful - see i.e. this example.

Answer 3

If you want to do it in the old-fashioned way (and trust me, you don't) then here is an example of how to do it (in principle):

http://svn.savannah.gnu.org/viewvc/apl/trunk/src/testcases/APnnn.tc?view=log

Have a look at all files APnnn*. In GNU APL the example only works with two APL workspaces that are running on the same machine, but with IBM APL2 they could reside on different machines. In the IBM case some additional configuration for the processor IDs on the remote machines will be required, so the example needs to be adapted a little.

Answer 4

yes, but ⎕SVO comes from a time where IP addresses were not commonly used (or even present). The left argument of ⎕SVO is a "processor ID", a concept similar to file descriptors.

GNU APL follows IBM APL2 except that APL2 allows a mapping from local processor IDs to remote processor IDs and IP addresses, That mapping is (in APL2) provided as an external config file and support for that config file is the missing bit in GNU APL.

In GNU APL, ⎕SVO was only provided for some backward compatibility with IBM APL2, so extending its syntax does not make much sense. For new APL applications it is much simpler to use UDP or TCP connections between processes directly, and ⎕FIO provides all that is needed for that.