Editorial: APL, Windows and GUIs

by Jonathan Barman

Exciting things are happening with APL and Windows. Dyalog/W APL and APL*PLUS II both have major advances in the integration of APL into the Windows environment. We have an extended review of the Windows features in Dyalog/W APL. In the next issue we plan to have an equivalent review of APL*PLUS II with Windows. Comparison between the two products will be quite interesting as the two vendors have approached the problem of integrating APL with Windows in completely different ways.

There is more to APL and Windows than just creating sexy looking dialog boxes. Sharing data between APL and other Windows applications is an incredibly powerful tool, and the article by Adrian Smith on Shared Variables in Dyalog/W APL shows just what can be achieved with a few simple functions. You can assign an APL variable and have the data immediately displayed in a chart. You can keep help text in APL variables and use a word processor to edit them directly. Entering data into a cell in an Excel spreadsheet can run an APL function with the results appearing immediately in the spreadsheet. The possibilities seem limitless.

Integrating APL with Windows could be carried out at the language level. APL is an old language, and was designed before any Graphical User Interfaces were thought of. The prime examples are ⎕ and ⍞ input which were originally designed in the heady days when connecting a typewriter to a computer was a wonderful achievement. It is amusing to speculate what APL would look like if it had been designed to be used with a GUI. Quad input would obviously open a dialog box. A standard interface would replace the hotch potch of session managers, function editors, ring editors, etc. that we have at the moment. However, a moment’s reflection makes the GUI interface seem to be but froth on the surface in comparison with the solid achievement of a language with a consistent and elegant syntax. I am not sure that the existence of a GUI would have really made all that much difference to the design of APL; after all, the design of J seems to have ignored any GUI aspects.

Smalltalk was designed from the outset with a GUI. Dave Ziemann has written a fascinating article where he solves the same problem in Smalltalk, APL and J, so that the three languages can be compared. The object paradigm of Smalltalk would seem to make the handling of Windows events easier, where a lot of the detailed programming can be inherited from parent objects which are provided as part of the language. In APL one needs to develop a library of functions to carry out the detailed work, and then life becomes simple again.

Aiming to get the maximum modularity and re-use of code is the same regardless of the language being used. In APL one uses functions and operators, and in Smalltalk one uses objects. Encapsulation seems to be more difficult in APL. Workspaces containing real applications usually have a plethora of global variables. Naming conventions are required to identify types of variables and to prevent conflict between utility functions and application specific functions.

Could APL be extended to include Object Orientation? My first reaction was that it would be impossible, but Robert Frey has written a paper suggesting extensions to J which seem to solve most of the problems. I find it difficult to assess the impact of suggestions like this without an implementation in which to experiment. The implementation of ⎕NA in APL2 is a stepping stone towards Robert’s suggestion. I have found it invaluable for improving encapsulation, and it completely removes the name clash problem.

APL must progress or die. Integration with the Windows GUI is a welcome indication that APL is alive and kicking. The ability to run APL functions and share data with other Windows applications seems to be a major advance.