Looking at APL2C

Dick Bowman

Contents

Introduction

APL2C is a new (or at least fairly recent) APL intrerpreter (and compiler) for which an evaluation copy can be downloaded from the APL2C web site.

Some aspects of APL2C are immediately striking

Return to Contents

Installation

After downloading from the APL2C site (the APL itself is about 1.25Mb, an Acrobat-format User Manual about 500Kb) installation is straightforward and no-frills; accept the defaults and you get a new folder called C:\APL2C.

On my Windows2000 box no Start Menu items, but that doesn't matter a lot (you do get a desktop shortcut).

Hit the APL2C.EXE icon and off you go (your 90-day evaluation period starts now)...

Return to Contents

What's in the Box?

After installation your APL2C folder contains APL2C.EXE and various support files.  No sample/demonstration workspaces are included.

On startup the APL session window is fairly plain...

You can select fonts, keyboard, etc. and turn off the APL symbol display at the bottom of the form (it can be used as a pseudo-keyboard).  I had a little trouble activating the (supplied) unified keyboard, but then - whatever it is - I always do.

The session works like Dyalog or APL2 (modify a line in-situ for re-execution) and so provides "true history" rather than the (to me) slightly muddled way that the J session does (where history is only true if you remember how the session works).  Sessions are saved on exit, so you can recall previous work.

So, after a first session - it looks like APL and it feels like APL. 

Return to Contents

How Fast Can It Go?

First job to do is to apply the "traditional" benchmarks of Greg Taylor; eschewing APL2C's )IN system command and transferring by cut/paste from an APL2 session (this process is about as klunky as it can get, but gives some grounding in actually using APL2C to edit objects and save workspaces - blame me, not APL2C).

This first phase is very frustrating:

The table below shows side-by-side comparison with APL2 Version 1.0 Service Level 2.

 
APL2/W
APL2C
INT ADD
4
5
FP ADD 
7.5
5.5
INT MULT 
9.05
5.5
FP MULT
7
5.5
INDEX 
0.8
1.2
CHAR COMPR 
1
1.5
INT COMPR 
1
1.5
INT+RED 
0
1
INT(times)RED 
0
21.5
BOOL SCAN 
123.2
46.1
MAT ROTAT 
1
2
CHAR TRANS 
0
3
INT TRANS 
1
4
VEC OF VECS 
7
2
PARTITION 
1.5
4
RHO EACH
0
4
VEC COMPAR 
0
1.5
INT SRT 
3.5
5.5
BOOL COMPAR 
0
1.5
IOTA 
4.5
118.5

Which (apart from the final iota) appear broadly comparable and suggest that APL2C is in the ballpark for acceptable performance.  I'm a little deterred by what feels like a rather awkward APLer-interface, but let's persevere...

Return to Contents

What Can I Make With It?

APL2C is a pretty fully-featured APL...

"Classic" APL

Coupled with a workspace size limited only by the operating system this is pretty promising; the only real practical difficulties are only being able to edit a single object at a time and the obsessive-compulsive way that the editor won't let you leave while it considers the object to be badly-formed (I use the editor as a jotter in other APLs and I can't here).

External (data) Interfaces

Well, the world is full of data and we want to read it, and we want to write it.

Component Files

"Not as we know it"; but for APL2C-centric applications there's a limited alternative which allows writes and reads of whole files containing single arrays.

I blow hot and cold over component files; they really should have been cleaned up and rethought when nested arrays came along and it's a typical outcome of the "joys of competition" that vendors who have component files have incompatible formats.

But they are useful (as a primitive "object filing system") in an APL-only context and it would have been good for APL2C to have been able to read component files of other vendors.

Native Files

This is better, not awe-inspiring, but OK (at least for character data).

The usual quadNxxx functions are present (with some idiosyncratic "improvements", for example monadic quadNTIE), but at this writing I can't find any way to read numeric data formats (there are system functions like quadREAL which look promising, but no joy as yet).

I shall try to return to this, and see if I can make a Tangram reader in APL2C.

Other Formats

Nothing that I can find, although I suspect that "plugins" are APL2C's answer.

GUI Applications

GUI functionality is offered through Tcl/Tk, which sounds like it might be a good idea (platform-independant).  There is an example and it runs (although I had to do what the manual told me and install Tcl 8.3.3 before it would run properly).

I don't know anything about Tcl beyond that it looks like a scripting language and claims to provide the same functionality across platforms (it originated in Unix, I believe).  The forms that I have seen have been fairly simple ones and I don't know how much control the programmer/designer has over look-and-feel or whether there is any sort of visual designer.

My trials were fairly fragile - if there's too much wrong with the Tcl the only recourse was to stop APL2C and start over (that old "save early and save often" training came in useful) - often seeing "attempt to address invalid memory" messages.

I think there's a good approach here - use external functionality so that APL development can be concentrated on the APL engine.  I'm not sure that I'll have enough confidence to be sure that it works in practice without learning a lot more about Tcl - and that may prove a significant obstacle for a lot of APL2C's potential market.

Return to Contents

Importing Your Existing Code

Bear in mind that this is being written sequentially (and I slowly gain familiarity, confidence and comfort).

)IN and )OUT are provided and allow code interchange with other APLs which have equivalent functionality; what I have to hand is APL2.  I've not been doing a lot of APL in this situation (using J for a contrast between work and play) so the available body of workspaces for import is limited.

APL2's Library 1 is one resource, and the DISPLAY and EXAMPLES workspaces transferred without problems.  MATHFNS transferred, but balked at complex number expressions, set of quadCT to zero and absence of quadES when functions were executed (none of this, of course, is surprising).  UTILITY offered a DOMAIN ERROR during )IN, and no hint about what the cause might be; but the bulk of the code was imported and seemed in reasonable shape.  The only real anomaly I discovered while doing these imports was a mysterious suspended function which gave me SYSTEM ERROR when I tried to clear it with )RESET and a shutdown of APL2C when I tried )RESET again.  Of course, there was no point trying to move any APL2 code which relied on Shared Variables and Auxiliary Processors.

A few home-brewed workspaces which had their origins in rather ancient Dyalog also moved without significant issue; it was nice to see that )IN noticed and tried to clean up some syntax problems (mostly unpaired parentheses) along the way.  Oddly enough, one of the workspaces moved was the Gregg |Taylor timing benchmark mentioned above and it ran without the idiosyncracies that bothered me when I tried re-creation by hand (just showing that time does make some things better, and the wisdom of using tools when they are provided).

Return to Contents

Making C

At one level an interesting party trick...

Looking at one of the old-time favourites, we find in apl_Average.c:

/*********************************
** Source file generated by
** APL2C - The APL Compiler
** http://www.apl2c.com
** DATE: 07/15/01 09:01:43
*********************************
**
** Compiled APL Function:
**
** [0] z{:=}Average w
** [1] @ Compute average
** [2] z{:=}(+/w){divide}{rho}w
**
*********************************/


#include "xxx.h"

aplarray *apl_Average(aplarray *_axis, aplarray *_larg, aplarray *apl_w)
{
aplarray *apl_z;
aplsymbol localvars[2];
unsigned char typeof_apl_w;
void *old_lines;
static char const0[] = "\27\0\0\0\101\1\1\103\1\0\0\0\3\0\0\0\3\0\0\0\0\0\0";
aplfnc func0;
aplop op0;


typeof_apl_w = A2C_InitArg(localvars+0, apl_w_idx, apl_w);
A2C_InitVar(localvars+1, apl_z_idx);
APL_InitLines(&old_lines, 2, const0);

nextline:
if (aplerrno) runtime_error(__FILE__, APL_GetLineNum());

switch(APL_NextLine(const0))
{
case 1:
goto nextline;
case 2:
APL_Assign(
apl_z_idx,
APL_Division(
NULL,
APL_Evaluate(
A2C_MonOp(&func0, &op0, APL_Reduce, NULL, A2C_Fn(43, 14340,APL_Add), NULL),
NULL,
NULL,
APL_Variable(apl_w_idx),
NULL
),
APL_Shape(NULL, NULL, APL_Variable(apl_w_idx))
)
);
goto nextline;
default: goto end;
}
end:
A2C_ResumeArg(localvars+0, apl_w_idx, typeof_apl_w, apl_w);
apl_z = A2C_ReturnVar(apl_z_idx);
A2C_ResumeVar(localvars+1, apl_z_idx);
APL_ResumeLines(old_lines);
return(apl_z);
}

I am somewhat impressed by this (all you interpreter-writers out there might have a different view, but I'm just somebody who writes APL and J to solve problems); unfortunately I couldn't take it any further because I don't have a C or C++ compiler on this box (I'm an APL/J programmer, why should I want such things? - maybe I'll get one and see what happens).

Beyond the entertainment level of course, there are some very worthwhile implications for this

There are a few (relatively minor) limitations, which are explained in the manual.

Return to Contents

Conclusions

APL2C is a very welcome addition to the growing list of APL (and APL-related) implementations and helps disprove one of the myths of APL (that interpreter-writing is such a black art that new interpreters cannot be written).

The major USP claimed for APL2C is the ability to generate C code from an APL source, and I admit that I have not explored this in any depth.

The most interesting direction taken by APL2C (for me) is the hookup to Tcl/Tk, and it is interestingly coincidental that I became aware of APL2C at about the same time that J developed an ability to use Tcl/Tk.  I will be exploring this shortly, but Tcl/Tk clearly opens up a possibility of APL/J as core calculating/processing engines (highly portable) and Tcl/Tk (also highly portable) to offer GUI - and other - capabilities.

The downside of APL2C is that I find it somewhat fragile, and it needs work in areas like the APL session (edit multiple objects, allow objects to be fixed with errors - at the very least);  APL2C is clearly less developed in these aspects than, say, Dyalog (although you could argue that Dyalog is over-endowed).

Last time I looked APL2C's costing was that it was free except for the C code generation, which means that it must be the candidate of choice for all those folks who are still running DOS APLs like APL2/PC and APL*PLUS SE in the Windows world.  My guess is that APL2C should have the potential to be ported to Linux.

A major question for the time-constrained is exactly how much time needs to be spent learning enough Tcl/Tk to write modern-looking applications (versus using the internal capabilities of Dyalog or J - or the others) and whether this outweighs the cost of a more "complete" interpreter.

But, it's free to look, APL2C is a modern APL, and you might be pleasantly surprised; my guess is that the more people are interested the better the chances that rough edges get smoothed off.  There is a very interesting product out there waiting for you to explore.

Postscript - as of 2006 it appears that APL2C is, at best, dormant.

Return to Contents


Copyright Dogon Research, 2001-2006