Compiling APL is not a new idea - all that has changed are the target platforms and the reasons for doing it. In the 1970s, the conference proceedings were well-filled with excellent papers, and several good compilers were written. STSC licensed theirs for a substantial fee, and Timothy Budd gave his away. Then it all went quiet. So why now?

Motivation

Back then, it was all about speed. CPU time was an expensive (and limited) resource - if you could save $1000 a day on your timesharing bill, then $100,000 was a reasonable annual investment. The downside was largely the training and expertise needed to get your APL code to compile, and (more importantly) to run it easily from the rest of your APL systems. Calling out to machine-code subroutines was never easy in those days!

In the 80s, timesharing died, PCs began to take over, and suddenly CPU time was virtually free (“use it now or it's gone for ever” as Alan Graham said at Manchester in 1986). APL systems that used to be CPU hogs ran in seconds on cheap hardware. Not surprisingly, compilers went out of fashion except for a few diehards like Roy Sykes and his ASMFNS libraries.

The .Net Advantage

What does .Net change? Firstly it takes away much of the pain. With Dyalog 11 and Santa Fe it is as easy to call a machine-code subroutine as it is to call a function in your workspace. It also offers a target language called C# that knows all about arrays. And an environment called the CLR that does garbage collection. The job of building a code-translator just got massively easier.

There may be other reasons why compilation is essential for .Net deployment

• “Pure Managed Code” is a badge that you might find you need if you want to have your system installed on production servers. It means that all your source code is provably safe, you don't use any pointers, and you don't call anything that isn't provably safe. Runtime APL systems won't be there for a little while, so compiling your code may be the only option. This was about 60% of the reason we converted RainPro.
• Unicode text. No current APL (apart from Santa Fe) can handle Unicode input. We ship SharpPlot to Korea, China, Hungary and so on. It absolutely has to accept text outside the normal range of 256 Windows characters. This was about 20% of the reason we gave up on the idea of shipping RainPro as a Dyalog runtime application.
• Lightweight DLL. APL runtimes of been getting a lot heavier recently, and most server-side code just needs a basic array-engine. Getting a runtime APL off the disk, throwing it the workspace (saved in your DLL as a resource) just so it can draw a piechart seems a bit of a nonsense. The entire SharpPlot download is about the size of the workspace. This was about 10% of the reason for moving to our own runtime library.
• Commercial stuff. Why ship your source code when you don't have to? It takes about 10 sec to extract the workspace from an exported Dyalog DLL. No way is anyone going to recover anything useful from SharpPlot!
• Speed. Sometimes this still matters, but for us it really was only the last 5%. Yes, SharpPlot is faster, maybe by a factor of 2 on a reasonable set of benchmarks. No, we really don't care.

There may be other reasons, mostly to do with company politics and product marketing. These were enough to convince us that we had to give it a try. The next page in this set puts a few typical APL fragments through the code-generation process to see what happens.