Power to APL

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

APL has come a long way since its inception many years ago, more years ago than we care to remember, not only in the enhancements and language extensions, and number of product offerings, but in the size of machines that can now support APL. It was not that long ago that DP managers for large mainframes were known to cringe whenever an APL user threatened to log on, but now implementations are available on micros the size of the QL. No longer is the number crunching mainframe required to support the number one programming language, but small relatively inexpensive micros such as the IBM and compatible PCs can be used with powerful efficient APL offerings.

However, anyone that uses these smaller machines knows that large amounts of computer capacity can be tied up performing relatively mundane activities such as formatting and neat presentation of data to the user. If data structures are large, bottlenecks are created in working with that data.

APL certainly is great for getting to the heart of the problem solving activities, but the interface to the user by way of screen and report presentation usually accounts for a large percentage of the program code, and normally for the CPU comsumption too.

We saw that there was a requirement to tackle these areas of user to APL interface, and excessive CPU consumption, to provide a powerful tool-box of useful but efficient functions and facilities, together with a simple but unique approach to the problem of program to user interface. We also saw APL as not being the true answer to this problem. We did not think that the efficiency problem could be solved by the usual ’box of tricks’ solution, or by providing the typical fullscreen management facility (like VS APL’s AP124) to provide for the program to user interface, this just replacing one nightmare by another.

The only really efficient coding technique that could solve these problems seemed to be Assembler, but to use this problem of interfacing APL to Assembler needed to be solved. This allows the Assembler code to be external to the APL interpreter, but utilises simple call structures and allows access to the symbol table to provide for variable reading and creation. Only by having the code external could the product be made really compact, and enable easy upgrading, for instance in forthcoming network environments.

The first step in the development was to generate the useful functions and evaulate the effectiveness of such a solution. We decided on the types of facilities required and broadly grouped these into:

• matrix catenation
• matrix index / membership
• string handling
• boolean handling

The boolean handling functions were a special case to us. We had decided to base our solution upon STSC’s APL*PLUS/PC offering, and in the current implementation boolean bits are actually stored internally as integer word zero and ones, consuming vast amounts of storage when large data structures are being handled. A complete ’compressed boolean’ operation set would dramatically affect any workspace utilising it.

Early developments showed that for many of the facilities implemented CPU consumption was something in the order of 10% of the APL equivalent solution. Preparation of data for presentation in report form to the user was now fast and effective, allowing the response time to be the domain of the problem solving code rather than to be extended by the user interface coding.

The second development stage was that of the Forms Processor. Here we were not looking for the standard AP124 Full Screen Manager solution, but a logical extension of the problem program. The program needs to create data that is presented to the user for his attention and possible modification or entry of new data. Restrictions such as screen size, data validation, incorrect keying should not be the constant worry of the developer, but of the user/program interface package, allowing him to concentrate on the real job in hand, that of problem solving.

We decided that the salient features of such a facility should be:

• Provision of up to 64K forms buffer into which a maximum of 31 forms could be stored, the number being dictated by the size of the forms in use. This buffer could be either the video memory (depending on size) or an APL variable.
• Display of any of the forms stored onto variable screen windows, allowing the user to ’drag’ the form under the current window.
• The forms should have fields, just as in AP124, with associated attributes, and no size restrictions.
• Support of various data formats, character matrix, fixed length fields or vector with field delimiters. Fields to be declared as character, numerics, with or without decimals, dates, etc., as required entry, fixed length, or multiple entry, etc., with the Forms Processor performing checks accordingly.
• APL functions to perform error checking or deriving data at field level, or any of the functions to be executed triggered by the change of a particular field.
• Overlapping fields, allowing the user to consider the fields as separate, but the APL function to treat them as an entity.
• Support for self sustained form overlay structures that could, if required, be held as components on a file.

These should combine to firm an effective solution to the problem of interfacing data to the user.

Evaluations showed that the screen handling was very fast, with movement, error checking, data validation, etc, being, to the user, instantaneous. Any time delay could be directly associated with the problem solving, and not the data display/user interface code.

We are of no doubt that APL has a tremendous and growing future, and that by working with it, and not against it, one can produce dynamic user-acceptable systems. To do this APL needs that added power that can be provided by tackling of specific areas of concern.

The solution lies in assisting APL in the areas it does not best suit, and combining the developments into an enhanced APL offering. In this way we shall see more and more APL systems on small desk top systems with users aware that APL provides a fast and effective solution to their problem solving requirements.