Coming back to APL after a lapse of about 25 years...
I tested (with great satisfaction !) NARS2000 on my Linux systems through Wine. It works. Well !
However, I am annoyed by the user interface design. While I have started my computer experience with... punched cards and Fortran, then 3279 terminals and TTYs, the mirocomputer was a revolution for me. I grew accustomed to the idea of having multple resources available at one time. X-Window and Windows quickly became indispensable resources for me.
But "The One Unix Way" suits me much better : each tool doing one thing, and used in cojunction with othe tools through various devices allows for a tailored working environment.
For programming/computing tasks, I grew very fond of Emacs : most of my everyday tools (R, C, Lisp/Scheme, TeX) can be used through this so-called editor which is in fact a very customizable development environment. My most usual working environment in an emacs session, with a window for TeX source, a R session communicating with the former, and possibly some C or Fortran windows for low-level code development (more and more rare nowadays...).
NARS 2000, in its current incarnation, does nor alow for such integration : the intrepreter listens and talks exclusively to its session manager. In impermeable ways.
I'd like to suggest to split the interpreter proprio dictu and the user interface, communicating through a two-way Uncode pipe/stream. This would allow to use emacs to integrate in the workflow, and possibly to use it as a standalone interpreter (e. g. "canned applications", and even shell scripting...). Such a split would allow running the interpeter on any (possibly remote) platform having C/POSIX development environment (that's almost all computing platforms currently in existence, except mainframes...). Including Unix, GNU/Linux and Mac OS X.
The user interface(s) could be tailored to the needs of the user's platform and references without interfering with the interpreter, which could indifferenty serve an emacs session, a 3270 emulator, a specialized Windows interface ... or another process.
A cursory look at the current code makes me think this is not absolutely impossible, even on Windows (which has somewhat limited interprocess communication facilities). But probably requiring some non-trivial work.
A step further in this direction could be to split the interpreter in a primitives library and a print(eval(read)) loop. This would 1) allow to use APL as a *library* for other programs to use, and 2) pave the way to a compiler (although I do not see a very big need for an APL compiler, I know that this subject remains a "hot topic" in some APL circles...).
What do you think ?