APL*PLUS II/386 Version 4
Vector 9:1, page 53
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 53
Background Review¶
Although I have used STSC’s APL*PLUS extensively on mainframes, I had not used any of their PC-based products before being asked to undertake this review. Consequently the opportunity to look at the latest version of STSC’s top-end APL for 80386/486 machines was an exciting prospect.
For many years, STSC has very successfully provided APL*PLUS/PC running under MS-DOS for 8086/88 (and 80286) machines. It is currently in its 10th version. It is however limited by MS-DOS’s conventional memory restrictions, effectively placing a 640k-byte ceiling on workspaces. In 1988, STSC launched APL*PLUS II with the Phar Lap DOS Extender to take advantage of extended memory above 1 Megabyte available on 80386 machines. This chip supports RAM up to 16 Megabytes. Workspaces could occupy most of that extra memory.
APL*PLUS II/386 is an advanced APL supporting nested arrays. A very pragmatic approach has been taken in providing ‘hooks’ for interfacing with the world outside APL. Various facilities have been added or improved with subsequent versions. The original product and Version 3 have been reviewed in previous editions of Vector [Cyriax 89; Askoolum 89; Pearson 91]. Version 4 brings a host of minor improvements and three major extensions:
- the ability to run within MS Windows;
- language changes aimed at compatibility with IBM’s APL2;
- extra windowing features including editing subwindows.
The latter two features may impact on existing applications code.
The Physical Product¶
A sizeable box contained three manuals (User, Reference and Utilities), an installation guide and a Windows Interface booklet. I was impressed with the documentation. It was easy to read and easy to refer back to later. It is a pity that the manuals are not supplied in ring-binders; keeping the page open with one’s elbow whilst typing in cryptic system function arguments requires some skill. But this is a minor criticism. The software was provided in compressed files on 6 diskettes in both 3½" and 5¼" formats. Installation was quite involved but generally worked the first time. Decompressed, the software uses about 10.5 Megabytes, but in practice this could easily be reduced to 5 Megabytes or less by picking out what you really need; there are over 4 Megabytes of provided workspaces alone. This compares well with other PC products such as Windows and Wingz.
There is also a rather nasty gadget called a Sentinel which fits on the printer port. The software will not work without it, and it is checked regularly. In my case, with a tower system beneath a work surface and the usual short leads all screwed to the back, fitting this device involved a bumped head, various scratches, and air so blue that even the dog felt obliged to leave the room. Although it can be left in place, I hope vendors of other software products I might install do not insist on a similar contraption.
The APL Language¶
STSC and IBM developed their nested array versions at about the same time in the early 80’s, broadly along the same theoretical basis (or heresy, some would say) adopting the "floating" methodology and strand notation. I believe STSC was the first vendor to provide a research system (NARS). There were conflicts with IBM’s APL2 in the final implementations in that some primitives acted differently and there were syntactical anomalies. STSC have nobly decided to move to the APL2 way "thus allowing the APL community to be more in agreement on an APL standard".
Version 4 of APL*PLUS II/386 will be the last to support the old (i.e. current) behaviour. It will also support the new (i.e. APL2) behaviour. This is achieved by an "evolution level" which may be set as a configuration flag or by the system command )EVLEVEL. To help detect occurrences of deviant behaviour in existing code, an evolution level of 0 will report an EVOLUTION ERROR on execution. Level 1 assumes the old and 2 the new behaviour. Primitives that are affected can be replaced by a system function that is independent of level, such as ⎕MIX or ⎕FIRST for monadic ↑. Strand assignment and indexing both require the strand to be within parentheses in level 2, e.g. (A B C)←data.
I know already from my mainframe experience with APL*PLUS that the nested array environment is both practical and productive. I am pleased to see that a blind-spot in the implementation - the inability to modify nested elements of an array below the top level - has been rectified with the introduction of selective specification for a subset of primitive functions. For example:
Otherwise the basic language remains unchanged, although the code for dyadic epsilon and iota is reputedly much faster at the expense of more temporary workspace.
The number of system functions has been further expanded. As well as the evolution level primitive substitutes, such as ⎕MIX, ⎕FIRST, ⎕SPLIT, etc., there are new functions to support windowing extensions (see below). Altogether there are now 172 documented system functions, variables and constants plus a few that are deliberately not documented. This compares with about 50 symbols used for primitive functions and operators. Adrian Smith’s controversial reference to ⎕KITCHENSINK springs appropriately to mind [Smith 87 and follow-up letters in Vector 4.4]. Too many system functions have arcane, highly parameterised arguments which contradict the underlying elegance of APL. Practical they may be but surely there must be a better way.
The APL Environment¶
STSC has developed a very nice text-based windowing environment which has seen further improvements in this release. Just about everything is configurable by the user, from the keyboard to the screen with your own choice of colours (from the admittedly small palette of 16 colours imposed on text VGA modes). You can set these parameters in a configuration file so that your preferred style is always presented on calling APL. However the default settings are reasonable, presenting a familiar APL desk-calculator look.
The session is recorded up to the limit of reserved disk space which you can set. Thus scrolling backwards and forwards is allowed. One or more lines of text may be edited and ‘dragged down’ to the current line for re-execution. Sideways scrolling has also been introduced so line wrapping can be avoided.
Previous reviewers have commented on the myriad of keystroke commands that allow you to do just about anything, such as opening lines, copying blocks of text, moving blocks of text and so on. Of course this requires a significant, non-transferable learning curve. Fortunately, mouse support has been greatly improved and most actions can be achieved with much less effort using the rodent.
Navigation of the edit environment has been greatly enhanced by a new box feature that provides facilities familiar to Windows users. The boxed surround includes vertical and horizontal scroll bars where appropriate, a zoom-in/zoom-out icon, and the edit window may be re-sized and moved by mouse drag actions. All very slick. A menu bar can be brought into view by mouse or keystroke action with pull-down menus to provide a variety of services. There is also a much improved help facility to which you can link your own customised help files for applications.
The keyboard can be configured in the familiar APL form or in standard ASCII form (or indeed in other standard or customised forms). In the former, ALT and ALT-Shift key combinations make the alternative APL/ASCII configurations available. Another way which I found easier is to switch character sets using ALT-CapsLock when mixing APL and ASCII text, e.g. in function definitions.
The full power of the editing facilities is extended to sub-windows in which functions, text or numeric arrays (up to rank 2), and text DOS files may be edited or simply browsed. Up to 32 sub-windows may be open at any time, and they may be rotated using keystrokes or moved to directly by mouse click. There are numerous ways of initiating an edit sub-window. The simplest is to double-click a name with the mouse or enter a keystroke combination with the cursor on the name. If the object exists, a sub-window is opened for editing. If not, a configurable default type is assumed which you may alter. Another way is to use the system command )EDIT. But perhaps most powerful is the ability to invoke a sub-window using one of the system functions ⎕ED or ⎕EDIT. Along with the new window functions, ⎕ECTRL and ⎕WCTRL, a great deal of flexibility is provided to build and manipulate edit windows under program control.
There is, though, a lack of debugging aids relying mainly on the now old-fashioned ⎕STOP and ⎕TRACE mechanisms. However, ⎕MF (monitor function) is made more useful by linking to a more refined timer.
Graphics Support¶
As in previous versions, APL*PLUS II/386 supports both the ⎕G-style of graphics inherited from the PC product, and also GSS*CGI graphics, a device-independent set of external routines interfaced through the undocumented system function ⎕CGI which you access using the utility functions in workspace VDI. The range of graphics drivers for the latter have been updated as "an optimal mix" from GSS*CGI Version 2.20 and earlier.
The External Environment¶
Those of you who have grown up with the home computer will be familiar with peeks, pokes and interrupts. Direct access to CPU memory locations was a way of life, and the only way to get the computer to perform certain tasks. STSC has provided the requisite tools for such direct control via system functions ⎕PEEK, ⎕POKE and ⎕INT in all of its PC products. Personally, I am not of this fraternity. It is with trepidation that I issue a ⎕POKE or ⎕INT knowing that it could seriously affect the health of my computer. STSC warns you of possible dire consequences, but then frequently suggests uses to achieve desired actions though normally relating, admittedly, to more advanced programming control such as windowing. You can set a flag via ⎕SEG to use the ⎕POKE location codes originally devised for the PC product, or you can directly access actual memory locations up to 1 Megabyte.
However, if you need to do these things there may be no other choice. The wider range of mouse options available through ⎕INT compared with ⎕MOUSE has been noted [Pearson 91]. I believe that the VGA colour potential has been ignored by APL but ⎕INT has proved useful in rectifying this omission [Smith 90; Crossley 91].
Two facilities for the more serious low-level coder are ⎕CALL and ⎕NA (for Name Association, I believe), the latter introduced in Version 2.0. ⎕CALL allows 80386 protected-mode machine code to be run directly from APL. ⎕NC allows programs written in a compiled language to be associated with an APL name which may then be run as a monadic function. Various C and FORTRAN compilers are supported. (Note that a new version of Phar Lap 386 is bound to APL*PLUS II/386 and Version 4.0 of the debugger may be required.) I accept the value of these facilities and will take advantage of supplied utilities, but personally I prefer to write my code in APL.
Microsoft Windows Interface¶
Does it work? The answer is yes, but the reality is rather like playing Snakes and Ladders; the elation of ascending each ladder is tempered by the disappointments of the snakes.
Of course, Version 3 of APL*PLUS II/386 could not even co-exist in the same DOS session as MS Windows 3. But a new version of the Phar Lap DOS Extender has cleared the memory conflicts. Version 4 runs in 386 Enhanced Mode of Windows 3. You can run APL as a non-Windows full-screen application. This allows you to use the mouse within APL and control the environment just as normal. To switch to another application, you must press the standard ALT-ESC key combination to return to Windows. The session you left is iconised. Double-click with the mouse on the icon to return to the APL session. You can have more than one APL session going if you like. All well and good, but is this really Windows?
Well, you can also run APL within a window, but then the mouse becomes transparent to APL so you will have to learn all those edit keystrokes after all. You must also reserve keystroke combinations in the PIF file to prevent interception by Windows. Just nine vivid colours are available which, it seems, cannot be altered.
However, you can write Windows applications driven by APL from a multi-window environment, which is probably an improvement on writing them in C. A very nice little booklet starts you on your way to becoming a Windows application writer, though you are expected to have MicroSoft’s Software Development Kit or equivalent to do the job properly. It explains the philosophy of Windows programming.
Essentially, your APL driver window (with defunct mouse) communicates with the (non-APL) application window via an APL Agent window. Windows programming instructions, issued through the supplied C-routines via utility functions, do things to the application window, such as creating menus, buttons, scroll bars and so forth. Events in the application window, such as keystrokes or mouse actions, are passed to the APL Agent window in coded form where they are displayed. The APL Agent can filter out events to pass on to the APL driver and leave Windows to take default action on others. For example, the application may be interested in a mouse left-button click but no others (and certainly not mouse movements without clicks which can generate hundreds of events per second). Thus the APL driver can take some appropriate action, such as perform a calculation or alter something else in the application window. The APL driver and Agent windows would of course be hidden when the application becomes operational.
The example application performed some quite complex tasks, such as building pop-up windows, yet was easy if long-winded to program. It is not really APL but it is moving in the right direction.
Yet More Interfaces¶
A great deal of software is bundled with APL*PLUS II/386. The Interfaces and Utilities diskettes amount to some 6 Megabytes when decompressed. There is far too much to attempt a review but here are a few snippets:
- an APL interface to Borland’s Paradox database product.
- full supporting workspaces for the IRMA 3270 emulation board.
- a user command processor to build your own system commands, plus a useful library of pre-defined commands.
- a Screens Interface Toolkit that enables you to build text-based screens based on
⎕WIN. - a report generator.
- workspace and file maintenance facilities.
- lots of programming utilities and development aids.
Conclusion¶
I may be wrong but I would guess that IBM’s APL2 holds the lion’s share of the APL market for small machines if for no other reason than a conservative tendency to devolve from the mainframe. However, STSC must dominate the non-tied market. And to quite a large extent, the development of APL*PLUS II/386 shows distinct signs of being market-driven. It satisfies a very diverse range of needs. There is probably a way to interface with most external devices and software, yet present it through APL.
Nonetheless, there does seem to be a lack of structure in the development process. The proliferation of system functions and variables is surreptitiously turning APL into yet another parameter-driven language. There is too much duplication and overlap — witness for example ⎕ED and ⎕EDIT. The commercial reasoning is understandable. Customers demand support for this or that facility now, if not yesterday. They may have invested much effort in writing software and having to change code to migrate to a higher version would not be popular.
The beauty of APL lies in its concise, orthogonal elegance which makes it such a highly productive language. To lose these qualities begs the question: why use APL at all? For APL to ultimately succeed, its underlying strengths must be exploited, new additions must sit comfortably within the APL framework. This requires properly thought-out design by APLers, not transplanted glitches from other orthodoxies. This is not solely an indictment of STSC but rather a serious question for all implementers to ponder. STSC has taken the bold step of moving towards APL2 in the interests of a common standard. Should not other language features be viewed in the same light?
But back to pragmatics. APL*PLUS II/386 is already a tried and tested product with a successful pedigree. What I had time to try was fast (though admittedly using a 40836/33 MHz machine). The session and object editors, particularly with the enhanced mouse and boxed windowing features, are very impressive. But the move towards integration with MS Windows 3, albeit not perfect, must for many existing users be the biggest inducement to upgrade. For first-time buyers, you get a very versatile and proven product with an enormous quantity of support software and distributed workspaces.
References¶
[Smith 87] Adrian Smith, Dyalog APL on the IBM6150, Vector 4.2, p53
[Cyriax 89] Peter Cyriax, APL*PLUS II: STSC’s Second Generation APL System, Vector 5.4, p55
[Astoolum 89] Ajay Astoolum, APL*PLUS II for 80386PCs, Vector 5.4, p61
[Smith 90] Adrian Smith, Lots More VGA Colours, Vector 7.1, p110
[Pearson 91] Duncan Pearson, APL*PLUS II Release 3, Vector 8.1, p73
[Crossley 92] David Crossley, Panel Design: An APL Programmer’s Toolkit, Vector 8.3, p74