Future Plans for Dyalog APL
Vector 5:4, page 78
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 78
New Screen Manager (⎕SM/⎕SR)¶
Dyadic’s new screen manager which went out on Beta Test before Christmas is now nearing final release. Although the basic design is unchanged, feedback from users has resulted in numerous improvements being made. In outline, the screen manager works as follows:
⎕SM (Screen Map) is a new system variable that represents the screen. It is used in conjunction with ⎕SR (Screen Read) which lets the user move about the screen and edit its contents.
⎕SM is a nested matrix which defines a form. Its rows represent fields, and its columns attributes. A field is a rectangular area with:
- contents (data)
- window position and size
- type
- behaviour
- video characteristics (inactive and active)
- position of window relative to contents
- scrolling groups (horizontal and vertical)
Field types include character, numeric, and date. Naturally numeric fields contain true numbers; there is no need to convert to and from text. Indeed formatting is handled automatically and includes fixed and variable number of decimals, triple separators, and continental formats. Dates are represented as numbers (number of days since 1st. January 1900), but are displayed and edited as formatted character strings. Date formats are defined in a file which allows any conceivable date representation and includes the facility to define the names of the days and months.
Field behaviour includes autotab, exit if modified, exit if invalid number, exit on entry to field, pocket calculator input (for numbers), and everything else you need to control user interaction in a sophisticated and efficient manner.
Data that is larger than a window is automatically scrolled both vertically and horizontally. Fields may be linked horizontally and/or vertically in groups that scroll together. Finally, the definition of ⎕SM is recursive so that a field can contain a form (i.e. a collection of sub-fields) and so on. This feature has two uses. Firstly you can define a form which is larger than your screen but which is viewed through a window the size of it. Sub-fields are then automatically scrolled into and out of view as the user TABs or otherwise moves around the form. The second use is for spreadsheet applications where the screen contains perhaps 5 forms (data, row titles, column headings, row totals, columns totals) all linked together so that they scroll or remain fixed relative to one another depending upon the direction of scrolling.
Assignment to ⎕SM¶
When you make an assignment to ⎕SM the change is instantly reflected on the screen. For example:
would immediately display that message in the 32nd. field on the screen.
Similarly,
would instantly blow up field 2 to the size of the screen (24 by 80) and change the colour of its contents to be red on blue.
One of the most exciting features of ⎕SM is its behaviour when it is localised. Dyalog APL has so-called ‘pass-through’ localisation. This means that a localised system variable is not undefined when you enter a function or operator. Instead it inherits the value from the calling environment until it is changed. When you enter a function in which ⎕SM is localised, the screen remains unchanged. However, as soon as ⎕SM is reassigned the new form is displayed on top of the existing one. Just like any other localised variable, shadowed values of ⎕SM are inaccessible to your program, but they are visible on the screen. When the function in which ⎕SM is localised exits, the local form disappears and the screen reverts to its original state. Localisation thus provides a simple and elegant means to do pop-up menus, help, etc.
Oracle Interface¶
The IBM Vendor-logo version of Dyalog APL for the IBM 6150 has an interface to SQL/6150, a special ‘cut-down’ implementation of the Oracle relational database. Dyadic has recently supplemented this popular feature by developing an interface to the full Oracle product. This interface is available not just on 6150, but on all systems that support Dyalog APL.
New APL Development Environment¶
Dyadic is in the early stages of designing a new development environment in which the APL session, the editor, and the stack are all integrated in a seamless fashion. It will fully exploit the workstation environment of a bit-mapped colour screen, mouse, etc., but will nevertheless be fully compatible with existing APL conventions.
Currently most APLs let you type an expression then press a special key (normally Enter) to EXECUTE it. We plan to extend this idea by adding keys that mean EDIT and TRACE. Furthermore the EXECUTE, EDIT, and TRACE keys can be mapped to buttons to give you a ‘point and click’ mouse interface.
If you type FOO and then press <TRACE>, the function FOO will pop-up in a window on your screen, and your cursor will point to the first executable line which will be highlighted. If you now press <EXECUTE> that line will be executed and the cursor moved to the next line. If instead you pressed <TRACE>, the line would be executed with trace on any defined functions and operators used on that line. For example, if the line traced in FOO said Z←AVERAGE Y, a new window containing the function AVERAGE would pop-up overlapping the FOO window. You could then single-step through AVERAGE or trace deeper into your application as you wish. Execution can be restarted at any arbitrary line by simply moving the cursor to that line and pressing <EXECUTE> or <TRACE>.
The function on top of the stack is always available for editing. Other functions and variables can be edited by pointing at their name and pressing <EDIT>. At any time you can have the SESSION window, the stack in several overlapping windows, and one or more edit windows active. You can move between windows with a single keystroke or by moving the mouse, and data can be cut from one window and pasted in another.
If an APL event occurs, the event message will be displayed, the stack automatically displayed with the top function in an editable window, and the cursor placed on the line at which execution halted.
AIX on PS/2s and Mainframes¶
Dyalog APL will shortly be available for AIX (IBM’s implementation of Unix) on PS/2s and mainframes in addition to 6150.
AIX on PS/2s will offer a similar environment to the IBM 6150, but with the emphasis on multi-tasking rather than multi-user facilities. AIX/370 will extend IBM’s Unix offering to a single operating environment spanning PS/2 workstations, departmental 6150 computers, and the corporate mainframe. As it runs under VM, AIX/370 will provide the means to integrate AIX-based distributed processing with mainstream DP applications and data.
IBM is putting more expenditure and effort into developing AIX than it is into PS/2s and OS/2 put together, and despite the apparent conflict with SAA, Dyadic expects AIX to capture a significant share of the commercial computing market in the future.
Dyalog APL for MS-DOS¶
Dyadic is currently working on an implementation of Dyalog APL that runs under MS-DOS on 386-based PCs such as the IBM PS/2 Model 80 and Compaq 386. The DOS version is based on the standard Unix implementation of Dyalog APL, but with changes necessary to move from a multi-tasking to a single task environment. The bulk of the interpreter, the component file system, line-editor, and even ⎕SM, already work and are demonstratable. However several tasks (including the completion of ⎕SM, and the new development environment referred to above) will be completed before the product is released. Performance of the DOS version is similar to that of Dyalog APL under Xenix. Under DOS the component file system is slower than it is under Unix, but highly competitive compared with other DOS APLs. Like Dyalog APL under Xenix, graphics will be supported by an interface to GSS*CGI.