FMT, FI, VISI, IDLOC, SIZEVR, DEF (vector function representations)ELX, ALX, SA)
Chris Burke is an actuary for Manufacturers Life in Toronto, Canada.
STSC's recent introduction of its APL*PLUS System II (SII) for 80386-based PC compatibles may be one of the most significant events in the APL world for some time. SII succeeds STSC's highly successful APL*PLUS/PC (APL/PC) as its flagship microcomputer product. Enhancements include nested arrays, improved handling of workspaces, and more.
APL/PC had some limitations, mainly a consequence of its dependence on the 8088 processor. I had hoped STSC's new interpreter would take full advantage of the 80386 and include fixes to the more noticeable shortcomings of APL/PC while maintaining essentially the same interpreter and close compatibility between the two systems.
What STSC has produced is different. You do get the expected 80386 enhancements, plus nested arrays. SII, however, carries over some of the problems of APL/PC and adds a few new ones. SII is twice as expensive as APL/PC, with no special price for an upgrade. It requires an 80387 coprocessor to take full advantage of its extra speed; and there are many changes from APL/PC, making SII incompatible with its predecessor.
Before getting into a detailed discussion of SII, let's take a brief look at the overall system. Once the basics have been covered, this review looks at the new product from the point of view of the APL/PC user, focusing on the enhancements that SII provides.
Like APL/PC, SII is an implementation of standard APL in the commonly accepted sense: A program written in standard VSAPL, not using shared variables or system-specific code, can be ported to SII and run with little or no modification.
SII includes most of the extensions to the APL language found in APL/PC. These extensions include:
FMT, FI, VISI, IDLOC, SIZEVR, DEF (vector function representations)ELX, ALX, SA)In addition, SII includes several PC-specific features found in APL/PC, such as:
CALL (to support machine-language subroutines)PEEK, POKEEDIT Full-screen editorWIN, WGET, WPUT
GPRINT, and so forth, for graphics managementCMDCHDIR)
New features in SII include nested arrays, and system functions, and variables such as ED, FHIST, PR, SAVE, and PSAVE. Missing are detached I/O facilities (such as /IN and /OUT), and several /PEEK and /POKE locations have been disabled. Also removed are the little-used system variables /KEYW, /HNAMES, and /HT0PIC.
I should mention that SII's workspaces and files are not compatible with APL/PC. SII has no means of reading an APL/PC workspace directly, but the system does include a workspace of defined functions that allow full access to APL/PC files. Thus, files can be transferred back and forth using these functions, and hence workspaces, via the standard functions WSTOFILE on the source system and FILETOWS on the target system.
SII offers several enhancements. Most notably, SII uses Phar Lap's DOS extender to run 80386 protected mode under standard DOS, Version 3.3 or later. Use of the 80386 processor has allowed STSC to make several fixes to APL/PC's shortcomings.
New are 4-byte integer and bit Boolean data types. APL/PC stored both in 2 bytes. In fact, APL/PC Booleans were one of that system's weak points. Not only did they take up far too much space but also the interpreter had no special code for Boolean calculations. In executing +/A=B, for example, the interpreter now knows A=B is Boolean and therefore is able to calculate the plus reduce efficiently. APL/PC did not do so.
Another enhancement is that there is no limit on variables nor a performance penalty for large arrays. Earlier versions of APL/PC limited object size to 64K. Although this limitation was relaxed in later versions, the manipulation of objects greater than 64K was rather sluggish.
There is, however, one caution. Because SII uses protected mode, \CALL machine language written for APL/PC will not work.
Workspaces are now limited only by the amount of available memory. (The theoretical limit is 2 gigabytes.) Part of the APL system (the DOS extender and APL session manager) is located in the first 640K of system memory, and the APL interpreter is located in memory above 1 Mbyte. Any other free memory above 1 Mbyte is available for the APL workspace. STSC recommends a minimum of 2-Mbytes RAM, leaving a workspace of about 750K. This compares to about 400K of workspace with APL/PC.
Several workspaces are supplied, including complex numbers, eigenvalue calculations, upload and download to mainframe APL systems, printer drivers, and some utilities. A major feature here is extensive support of GSS*CGI graphics, which consists of a workspace plus several files accommodating a wide range of graphics devices.
SII now includes a fairly basic nested array capability made up of the following:
Enclose, split, and mix can be modified by the axis operator. SII also supports strand notation and scattered assignment, and it allows user-defined functions as arguments to operators. User-defined operators, however, are not supported.
Nested arrays presented one pleasant and unexpected surprise when I reviewed the system. My programs typically depend on the ability to package APL objects (such as representing a list of APL objects in a single object). In using SII, I was initially concerned that most of my systems would not work without a good package capability. Of course, programmers can implement packages with ordinary APL functions, but I had expected this to be much too slow, as it had been with APL/PC.
Nested arrays came to the rescue. Using them I was able to write, in a couple of hours, a complete package emulator that is efficient enough for general use. The package runs an order of magnitude slower than the APL/PC assembler functions, but I find that acceptable.
Indeed, only a couple of problems remain to be solved before dispensing altogether with assembler or system package functions. Because emulators store functions in their vector representations, locked functions can't be handled, and the intermediate compilations produced when a function is first executed are thrown away.
Several enhancements have been made to the user interface. A session manager, implemented independently from the APL interpreter, now handles the APL session and one or more edit sessions (the ring editor). New functions that you'll find include search and replace (in any session), copy or block move within or among sessions or APL objects, undo several erasures, restore current line, and search for matching parenthesis or bracket. Especially useful are token search and replace and the ability to set stop and trace when editing functions. Additionally, pop-down menus provide an alternative means of selecting various options.
Various keystrokes have been added and others changed to support these capabilities. In fact, the underlying keyboard driver itself has been extensively redesigned. Some changes would be needed to APL/PC functions referencing keyboard numbers, but overall, the use of the keyboard is much better and more logical than with APL/PC.
There are a couple of minor problems, though. A drawback to the new ring editor is that only one editing session at a time can be handled under program control. Also, the session manager appears slightly slower than the APL/PC when displaying output.
Like APL/PC, SII offers both the traditional APL keyboard and a text keyboard called the Unified keyboard. I am not happy with either. The traditional APL keyboard is a nuisance to use because it remaps several standard keys, such as the apostrophe, colon, and semicolon, to new positions. Thus, it is difficult to become fluent in both the APL and standard keyboard layouts. The whole question of the character set and keyboard layout was hotly debated a few years ago in the APL industry for this reason.
Two different solutions were proposed for the PC, both using Alt or Shift-Alt key combinations to represent special APL characters. The main difference lay in the choice of the primary alphabet. STSC's Unified keyboard treats the uppercase alphabet as primary and lowercase as emphasized, whereas Sharp's Union keyboard uses the reverse. In retrospect, it is quite clear that the Union keyboard is correct; it follows the normal practice of written languages and computer languages that allow both uppercase and lowercase alphabets. In practice, I find the reversal of the usage of uppercase and lowercase alphabets in the Unified keyboard disconcerting, and I still use the APL keyboard (as does nearly everyone else). At some stage, STSC should reverse its policy and its alphabets!
The documentation is up to STSC's usual excellent standard. It includes a comprehensive reference manual, a users' guide, a manual of GSS graphics, and a pocket quick reference.
I have used STSC's customer-support help line several times and am happy to report its staff members are invariably courteous and efficient. STSC also goes out of its way to ensure that a variety of hardware is supported by its system.
Several minor improvements are noteworthy. First, note that screens other than 25 rows by 80 columns are now fully supported. Also, notice symbol table sizes are now increased automatically so that using )SYMBOLS when first creating a workspace is unnecessary. Maximum symbol size is now 32767.
Improvements to the default formatting of numbers are as follows. First, formatting of small numbers switches to exponential notation only when the exponent is - 7 or smaller. In contrast, APL/PC had exponential notation starting at - 3, which often produced unreadable numeric displays. Second, numeric matrices are now formatted column by column so that each column is formatted to its own width instead of to the width of the widest column. Curiously enough, formatting of numeric matrices in APL/PC was so slow that it was more efficient to format using a defined function that formatted each column separately and catenated the results. Even in SII, using the defined function is only marginally slower; clearly an inefficient algorithm is being used here.
Printer support is extensive, but perhaps I might make one request. I use a LaserJet II printer, for which STSC provides an APL font. It's a 12-point font, however, which is too large for function listings. Condensed mode is an improvement but still is still unsatisfactory. I'd like to see STSC supply APL fonts in a variety of sizes.
SII does have a few problems. To start with, there are some changes that bring little or no benefits, yet they invalidate a lot of existing software, making life more difficult for programmers.
For instance, automatic formatting applied when defining functions has been disabled, leaving the original source unchanged. This formatting was extremely useful: It made code much easier to read; it meant programmers need not waste time manually prettying the code; and utilities such as line relabelers, comparison functions, and search and replace functions could take advantage of the standard format.
STSC supply a utility [triangle]VR, which (supposedly) converts any vector representation to either its canonical vector representation in APL/PC or a similar representation in SII. In neither case, however, does this work correctly!
Next, APL files can now be accessed by giving their DOS path rather than the APL library number used previously. (Incidentally, the library number is still recommended by STSC for compatibility.) Thus, rather than referring to a file as 11 TABLES, I can now use a few more keystrokes and enter C: \APL\UTILS\TABLES. This seemingly innocent extension confers no real benefit to users, but it has the serious drawback that code accessing APL files may no longer work properly and algorithms that access files have to be much more complex than before.
A related issue is that there is no longer a default APL library, which raises the question of how to access a file or workspace given only its name (not its library number or full DOS path). This feature was especially useful in systems intended for distribution when the library number or DOS path was not known in advance.
This was a real surprise for me. On my machine, there is no overall significant difference in performance between SII and APL/PC. In fact, some common functions consistently perform slower in SII. An example is the standard vector-to-matrix utility, which typically runs about 20 percent slower (even after compilation). These results differ from STSC's advertised speedups of between 50 to 500 percent. There are, however, several factors to take into account.
The use of 80386 machine language should, in theory, enable quite significant improvements over the same programs written in 8088 code. I suspect this has happened but has been offset by the more complex interpreter required by nested arrays.
TSC strongly recommends using a coprocessor (which I do not have) because SII makes much better use of coprocessing than does APL/PC. In particular, with a coprocessor on-board, STSC claims a six time speedup for integer arithmetic and four times for floating-point arithmetic and mixed primitives. The company's claim for overall speedup is more modest: 30 to 50 percent in total processing time.
SII also has a form of intermediate compilation for its functions. The first time a function is executed, it runs slowly while the function itself is internally redefined. It runs faster the next time around. The vector-to-matrix function, for example, doubled in size from 532 bytes to 1,024 bytes, while timing improved about 12 percent. This is nice, but it requires functions to be workspace-resident. Those who pefer to store their systems on file (essential for large applications) will find there is no way of storing the compiled code, so functions must be recompiled each time they are run.
I think it's unrealistic to use standalone benchmarks to compare the performance of SII and APL/PC. The larger workspace of SII allows more data to be operated on simultaneously and can allow more efficient nonlooping algorithms to be written. The use of 4-byte integers enables more use of integer arithmetic rather than floating point, and bit Boolean manipulation is much faster than with APL/PC's 2-byte Booleans.
The overall performance of systems written in SII should therefore be better than those written with APL/PC -- even for users without a coprocessor. At the same time, there appears to be some room for improvement in efficiency. APL/PC users hoping to move up to a blindingly fast implementation may be disappointed.
Overall, SII is a more attractive product than APL/PC. In particular, it fits in with STSC's long-term strategy for its PAL product range. In the past, STSC has been criticized for supporting too great a variety of APL interpreters, which were not closely compatible with each other and which apparently stretched STSC's development resources too thin. The plan now is to support one primary product, the Portable APL*PLUS System, with implementations on the PC (SII), VAX, and various Unix machines; 370 (VM\XA and MVS\XA) implementations are to follow. APL/PC will continue to be supported but will not become part of this product range. Sooner or later, therefore, serious users of APL/PC will want to bite the bullet and make the change to SII.
Copyright © 1989, Dr. Dobb's Journal