Please refer to the following foils which were presented at this meeting:
APL2C - George Gawenda - ggawenda@idirect.com
Our evening began with George's presentation of his comments about the APL2C APL compiler, which is freely available as source code and may be installed on a system with the Gnu C compiler, such as Unix (including Linux) or DOS.
The APL2C compiler is the result of Sam Sirlin's work over the last 7 years based on Tim Budd's original APL compiler. It can be downloaded from Sam's ftp site at: ftp://csi.jpl.nasa.gov/pub/apl/apl2c
George began his talk by explaining how to obtain and install the compiler, in his case, using the Linux operating system. Linux, we learned, is just like Unix, only free or close to free, and works like magic on Intel/PC machines. One crucial point to note from an implementation point of view, the APL compiler in fact creates C code, which is then compiled by the Gnu C compiler.
The APL compiler offers a fairly simple flavour of APL programming, no workspaces, no component files, no enclosed arrays, no GUI, no interactive debugging. It uses a transliteration scheme for substitution of APL characters, eg. .lmp = comment symbol, .le = less-than, .bxio = quad-IO, etc. According to George, "The list of basic APL primitives seems to be there, however some have behaviour which may not conform to ISO standard, and there may be numerous edge conditions which could possibly provoke unusual behaviour. A well, there is a useful list of system variables and system functions. The compiler however does offer useful error messages at compile and run time."
Of course, the real catch when working towards compiled APL is the observance of datatype for all data objects. As George points out: "Although declaration of variable types is not required, and the compiler does a good job when a variable is declared as a "variant", some care need be taken since the compiler can make mistakes in this rather difficult area." Directives exist to "declare" variables in terms of rank and datatype when creating functions. Unlike for example in the interpreted APL environment, integer data objects are not automatically scaled up to real numbers when required. Anticipating these changes becomes a factor in one's programming for compiled APL.
Also, booleans in this APL are handled as integers, even though boolean does exist as a valid datatype. The up-side is that compiled APL typically took a lot less memory to run compared with the interpreted version, according to George's testing so far, so perhaps this isn't an issue.
George discussed how much trial and error was involved with datatype declarations and other quirks in order to get some compiled code to work. Debugging of compilation problems, he mentioned, was not a trivial exercise. By way of example, George mentioned that "...a program with more than 300 lines of APL source code was converted in a day. Excluding time learning compiler use and idiosyncrasies, it would probably take half a day".
In terms of performance, limited testing to date indicates that compiled efforts sometimes performed worse than a DOS-based interpreted APL, but again the much-reduced memory requirement could be a big plus for certain applications.
As far as the future is concerned, George pointed out that work seems to be continuing on the APL compiler, although it is not clear what the schedule is for this. George points out that "...an updated release of the compiler has been appearing monthly or more frequently at the download site." And he adds: "...since the compiler produces binary code in the Gcc environment, it offers another way of linking APL code to code written in other languages, and offers APL on platforms where it may not be otherwise available"
In summary, this tool could have potential benefits for certain specialized applications in need of highly optimized code at key points in the process. It certainly won't replace full-blown interpreted APL applications but could be used to implement critical speed-ups in some cases.
APEX - Bob Bernecky - bernecky@acm.org
Bob Bernecky was on hand to entertain us in the second half of our compiled APL evening, presenting a brief but enlightening demonstration of his APEX compiler, running under WinNT on a laptop.
The full story on APEX can be viewed at Bob's MSc Thesis website, at: http://home.ican.net/~bernecky
APEX works by using APL itself to analyse APL code and produce SISAL code, an intermediate step before creating C code which is then compiled. The end result is a highly portable executable nugget of code which can be run on almost any machine. According to Bob, the SISAL phase of the compilation process introduces some benefits in terms of what might be called "data typing discipline" to the exercise. This then translates to implementation and performance benefits later.
After three or four excellent demonstrations of going from raw APL code to compiled .dll, we began to get a good idea of what the compilation process was all about, how much work is involved, what sort of speed-ups are possible, and so on.
Again with APEX, as with the APL2C compiler, vanilla APL is all we can use, although in the APEX case Bob suggests that more features will be added later as demand and time allow. Features such as enclosed arrays, event trapping, etc. are still some distance in the future.
Bob then went on to discuss some of the benefits of compiling APL besides the considerable performance speed-ups, which he ably demonstrated using an APL interpreter to run the original code and the compiled code via the quad-NA interface. These benefits included having a more readable and maintainable APL (due to the strict adherence to clean, simple APL needed for compilation to work), the removal of explicit loops by the optimization phase of the compiler itself, the portability of the final product, etc.
As before, we discovered that compilation makes sense for situations where a significant performance bottleneck is causing problems. It does not provide major advantage over interpreted code for small one-off jobs working on small datasets.
In conclusion, it would appear that compiled APL has a role to play in the future of APL systems, for enhancing key sections of data-intensive applications where the memory requirement and performance limitations of interpreters makes the problem difficult.