Review: IBM’s APL2 on the PC (16-bit)

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 45

IBM Product 38F1753 (APL2 for the IBM PC Version 1.0).
Price £348, available now from authorised IBM dealers.

Background¶

Having used APL2 in a mainframe environment for several years I’ve tended to feel a little reluctant to do PC-based development in the recent past; I value the expressive power of APL2’s language enhancements and am frustrated when these things become unavailable to me. I think that one of the essences of APL is fast problem-solving, and the restrictions imposed by the implementations hitherto available in the PC environment can be very real ones. Depending on your particular application they can outweigh the benefits of improved user interface and so forth which are achievable on the smaller machines.

The product at hand is therefore exceptionally welcome; it offers the opportunity to use APL2 on your PC or PS/2 at a reasonable price (and I firmly believe that we have to see APL offered at prices comparable to those of other languages).

Hardware Requirements¶

In brief, any sensibly-configured PC or PS/2 should be satisfactory; this review was performed using a 640k AT equipped with EGA adapter, monitor and 80287 coprocessor. The product is supplied on both 5.25 and 3.5 inch disks. In fact you also receive two versions of the interpreter, one for 16-bit hardware, the other for 32-bit; regrettably I was unable to investigate the latter.

Does It Feel Comfortable?¶

Subjective impressions are hard to quantify, but important; in many ways this is the main question I was looking to answer. What I wanted was a sense that unless I deliberately intended to use specific machine features I should be unconcerned about whether I was using APL2 on a PC or a mainframe system (my reference frame is APL2/370 Release 1.3, running under TSO on Amdahl hardware).

Installation was straightforward, to start APL2/PC there are two steps (easily automated)…

a) Load the APL2 character font; an option provides a 43-line display if you use the EGA adapter - I found it acceptable.

b) Decide which Auxiliary Processors are needed for your session and start APL2 with this set. In fact APs may be added and discarded at will - and there are workspace size benefits from using only the necessary subset. As you correctly surmise, APL2/PC follows the IBM party line about using APs to provide facilities outside the core language; which is alright by me, but it is definitely different from ⎕EVERYTHINGUNDERTHESUN.

Once started there’s a very strong impression of responsiveness which contrasts most favourably with TSOlag. Keyboard layout is ‘IBM normal’ and how you take to this depends on how conditioned you are to expect specific layouts on specific machines - if it’s a problem you can reconfigure the keyboard as necessary; with all of the ‘new’ APL2 symbols present the default layout is reasonable although I’d very much like to see an agreed keyboard once more (both the IPSA ‘union’ and STSC ‘unified’ have their merits, even though they differ from one another). Expected, present, and welcome is a type-ahead facility - something which is annoying by its absence on APL2/370.

You have a choice of interface style; either ‘PC-normal’ with a continuous scroll or a session manager format which is a close approximation to that of APL2/370. Given that the latter is preferable in my accustomed mainframe context I used it most - although given a fully free choice my ultimate wish-fulfillment would be continuous scroll in both environments. The main irritation I get from the discrete-page style of the session manager being that the most interesting bit is always at the bottom of the page; on the mainframe PF8 is an escape valve which allows you to force a page throw. This doesn’t work properly with APL2/PC.

Another (minor?) annoyance stems from my preference to use the non-default DISPLAY HOLD OFF option so that long output sequences come to their natural conclusion without my personal intervention. Although the session manager has a compatible look-and-feel to the mainframe version implementation is different and it’s not possible to save a personal profile; what you have to do is to set the options up as you begin your session (again, you can automate the process).

Having made contact with an unfamiliar APL system my first instinct is to type )LIB and see if there are any interesting toys to play with; APL2/PC provides a novel response in that the display resembles ‘DOS DIR’ format rather than the conventional APL style - there’s more information presented, but it does tend to overflow the page. A full set of workspaces come with the product in the accustomed IBM manner - for the sake of familiarisation I looked at two of them…

AP124

An emulation of the obsolete mainframe Auxiliary Processor 124 for alphanumeric panel use is accessible via this workspace. All the facilities you were accustomed to in the days of VSAPL are present, augmented by functions FSSCAN and FSINKEY providing the immediate response so necessary for PC applications (indeed, all applications) and analogous to STSC’s ⎕INKEY function. I didn’t have enough time with the product to explore the discrepancy between this workspace offering only a 25-line display and the clear evidence that 43-line support is achievable - possibly a documentation problem.

GRAPHPAK

Another old faithful rears its head; the demo worked fine except that the documented instructions were missing. A major disappointment was that graphics were restricted to CGA compatibility.

At this point I felt that I had established that an APL system existed, it had a fairly familiar feel and seemed subjectively quite fast; the logical next step was to quantify the performance.

Duz APL 2PC Run Fst?¶

I have two reference points for performance; STSC’s APL*PLUS/PC (Version 6.0) and mainframe APL2/370; using the customary benchmark set (see VECTOR Vol. 4 No. 3, p. 40) the following results are achieved…

                    STSC  APL2/PC   RATIO   APL2/370
Z←+/VI                17       27   1.588         .1
Z←∨/VL                 1        0    .000         .1
Z←⌈/[1]MI             11       16   1.455         .1
Z←VI*.1              197      258   1.310        2.6
Z←|VR                 34       27    .794         .1
Z←VR[VI[⍳20]]          5       11   2.200         .1
Z←VI[⍋VI]             43       61   1.419        1.2
Z←¯2 1↑MR             12        5    .417         .1
Z←VI∊VI               55        6    .109         .8
Z←2 1⍉MC              22      132   6.000         .2
Z←VC∘.=VC             38       34    .895         .8
Z←(⍳50)∘.+⍳50        154      121    .786         .8
Z←VR⌊.+VR             98       99   1.010         .2
Z←MR⌹10↑VR            82       94   1.146         .7
Z←FIB               1170     1395   1.192       14.5
Z←VR×3.14             49       38    .776         .1
Z←VR÷3.14             61       50    .820         .3
Z←⍟VR                 89       82    .921         .7
Z←1○VR×.1            224      231   1.031        1.8

AVERAGE                             1.256

All times are in milliseconds; with a clear workspace for both systems ⎕WA is 357152 for APL*PLUS/PC and 335792 for APL2/PC. I think this is quite a reasonable performance; I also include the mainframe figures for their academic value - they show quite clearly that big boxes really are fast once they get going (it’s just a pity there has to be so much hardware between you and the CPU to make the response time bad).

So much for ‘standard’ APL; to date I haven’t seen many benchmarks for the newer features and I offer the following as a starter set…

NEST←2 2⍴MC VI VR

(2 2⊃NEST)←⊂NEST

                  APL2/PC     APL2/370
Z←VR≡⌽VR               83           .1
Z←⊃⊂[⎕IO]MC           241          1.5
Z←∊NEST              1917          1.6
Z←5+/VR               620           .4
Z←∊⍳¨VI              2197         13.1

A set of results which I find somewhat less gratifying.

Much time and effort can be spent on benchmarks - I don’t think any of the above are without flaw; I know of other people who’ve looked at the IBM product and produced better figures for it, no doubt STSC can come up with their figures as well. Add weighting factors to taste. For my purposes I’m happy that APL2/PC is at the very worst comparable to the well-established APL*PLUS/PC product.

A Small Application¶

Undaunted, the next task was to look at a small application and assess any problems in its implementation; just to make a change from the routine this was an application which takes data from a digitising tablet and converts to Ordnance Survey grid references. An incarnation using APL*PLUS/PC has been in use for several months, so the requirement is well understood - the questions being how closely would the two versions resemble one another and how ‘usable’ is APL2/PC.

Function editing is the first thing to sort out - APL2/PC has an inbuilt editor which is fairly rudimentary, but a pair of alternative fullscreen editors are provided within one of the supplied workspaces. Most of my time was spent using one of these (EDIT2) - it provides an excellent set of edit capabilities. Nevertheless, it has an inherent problem deriving from its own nature as an APL function; if you edit a suspended function you resume execution with the function as it was before you edited. Which is not particularly good news if you’re trying to do some serious debugging; APL2/PC sorely needs a fullscreen editor like the mainframe )EDITOR 2 (which for all of its defects at least lets you change the suspended function and resume with the new version). Even though EDIT2 is reasonably fast time-lags are noticeable and one might expect an intrinsic editor to be faster.

The next ‘problem’ is language incompatibility with APL2/370; there are a number of problems here which I regret, in particular

a) Restrictions on the use of axis specification

b) Selective specification isn’t implemented at all

I find the latter most intrusive, because it tends to run naturally with the index function (which is implemented) and stylistically I would prefer to live without bracket indexing.

The application in question accessed a digitising tablet attached to the AT’s COM1 port, which led to quite different code detail. The APL*PLUS version takes its input using ⎕ARBIN statements; APL2/PC uses AP232 (in my case via the supplied cover functions). Once acclimatised to the different style everything’s fine and works well - but I can’t underemphasise that this is not just a funny version of the STSC product and that this has to have some influence on your detailed coding. I don’t think either product has a monopoly on ‘good’ - they’re just different and if you can’t personally live with that then too bad. There was originally a problem in getting started, documentation and workspace differing from one another about setting parity options; the resulting error messages are none too helpful. I ran into this generic problem rather more frequently than I would have liked to, I feel that someone ought to smooth out these differences.

Another minor problem encountered with the AP120 session manager was that sometimes overtyped entry wasn’t fully re-executed; most of the time it was alright, but occasionally it wasn’t.

Graphics¶

Let’s not beat about the bush; unless you have the readies for extra hardware like the 8514 monitor, or extra software like the Graphics Development Toolkit, APL2/PC graphics capabilities are pretty grim. Grim as spelt C-G-A.

I have a personal bias toward graphic applications, so I felt that after several years of at the very minimum EGA systems, this was more than a little miserable.

What there was worked fine, and if you don’t need graphics it won’t be very upsetting to not pay for what you don’t want. But, if you do, then be ready to spend some more money. As the Enid Lumley of APL I was unable to explore the more exotic alternatives.

What Can/Should APL2/PC Be Used For?¶

So far, this might all seem grim reading; but I feel positive about the product - I’m sure it fills at least a niche, and probably a quite large one.

So far I’ve not commented on what I think is the most important innovation APL2/PC brings us - grandly called the Application Package Maker and with a description furtively hidden on pages 347-348 of the manual. What it does is very simple; it takes your APL workspace and converts it into an executable DOS file. Which means that whenever anyone calls you and wants a one-off solution to a computing problem, if you can come up with an APL2 solution then you can package it and ship it out with no fuss or ado about them having to have an interpreter of their own, or a run-time version, or indeed anything that costs money. Economies of scale were always good for multi-copy run-time APL applications, what IBM have done (and, to be fair, MicroAPL before them) is to make APL realistic for the cottage industry.

Another area I see particularly attractive is multi-environment systems; now you can use essentially the same APL on both the mainframe and micro components of the system. I can live with the niggles, if it means I can use the same utility code everywhere.

An option I find surprisingly less attractive is use of the PC as a local responsive development environment; I think the differences from the mainframe product might be more of an obstacle here. I suspect that a great deal of mainframe APL also has to concern itself with interfaces to other systems and languages which by their nature are not present on the PC; also the relatively poor editing options of the present APL2/PC product for me outweigh any gains in responsiveness. Also take a look at those APL2/370 timing figures if you’re embarking on heavy computation.

Other aspects of APL2/PC which could be factors are AP488, which provides an interface to GPIB/IEE488 hardware, and what looks to be a quite detailed explanation of how to write your own auxiliary processors.

What Improvements Are Desirable?¶

The most irritating aspect of APL2/PC ought maybe to be the easiest to achieve improvement with; there are too many places where the manual and the reality are inconsistent.

It seems to me that one of the most positive aspects of STSC’s APL*PLUS/PC product is that it has a support structure; this would appear to be a major factor for success and I’d like to feel that IBM could set up a scenario by which APL2/PC queries could be handled promptly and easily (to some extent this also has to come from the users themselves). In all fairness my own problems were always dealt with in an exemplary manner, but I’m a little worried on behalf of Tom and Harry.

Graphics and editing are glaring weaknesses; the former may not concern everybody - but I definitely feel that both need attention.

And for a final shot, I’d like the gap between APL2/370 and APL2/PC to become smaller.

Conclusions¶

This review may sound negative - perhaps that’s the nature of such things. But I wouldn’t like to leave you with the impression that I condemn the product out of hand. Far from it; I enjoyed using APL2/PC, I intend to switch the PC end of my applications onto it, I look forward to sending out run-only APL applications without an interpreter order form. And above all, I look forward to having some of those end-users decide to try APL themselves because they liked the flavour of what they got.