Editorial: Commercial APL

by Jonathan Barman

I was deeply impressed with the BAA meeting at Morgan Stanley. We saw a vibrant APL community producing systems crucial for the survival of the business. Speed of development and speed of execution were both vital, and APL and its relative A were delivering the goods.

Morgan Stanley’s in-house development of A was fascinating. Here is a small team developing a language which has got to be better than anything that is available commercially. New features can be included quickly, and as there is a relatively small number of users, changes to the language are not a big problem.

Commercial APL has to have features. Every vendor makes their APL special in some way. The process of including a new feature is often a lengthy procedure, requiring surveys of user requirements and analysis of discussions at user forums. There is always the problem of upwards compatibility. It is essential that existing customers can continue to run the code that may have taken considerable amounts of time and money to create. The vendor will want to select those features that will appeal to the widest possible audience and will help to sell the product.

The aims of the developers of A at Morgan Stanley are, therefore, rather different from the developers of commercial APLs. What is so interesting is to see the features that the Morgan Stanley developers have decided to include, and, equally interesting, the elements of APL which have been removed. How would you get on without being able to branch to a label? Phil Last and Gérard Langlet have both written articles in Vector showing that they abhor branching, so they would be delighted by such a move. But the majority of APL programmers would, I think, be in some difficulty without it. I cannot imagine any APL being sold where the branch arrow had been removed.

There are several facilities in A that I would love to be available in standard APL. The Name Association ideas in APL2 have been taken a stage further in A, where they are called Contexts. I feel that this type of facility is one of the key things missing from APL. Dick Bowman, in his article Seize the Time, bemoans the fact that there are so few APL toolkits available. In my view this is a symptom of the absence of a facility to bundle up groups of functions into an independent library. In C one can buy libraries of functions distributed in object code format, which can be used but you cannot see the source code. Functions can be locked in conventional APL, but this is not particularly secure. Libraries of machine code utilities are available, but when APL crashes there can be disputes about whether it is the interpreter or the library that caused the problem. A decent library facility could encourage the sale and distribution of toolkits.

One cannot buy A, it is not APL, so the interest is somewhat academic. But there are lessons to be learnt on how a language can evolve to solve real commercial problems, and therefore what features should be included in future versions of APL.

In the last issue of Vector I promised a review of the APL*PLUS II/386 Windows interface. I was looking forward to seeing how it stacked up against Dyalog APL/W as I knew it took a quite different approach. Also, I hoped to see some clever ideas which would mask the complexity and difficulties in programming Windows. Unfortunately, the whole thing is rather a disappointment. Obviously one can make it work, and every Windows function is available, but it would seem to take much more skill and effort than is normally associated with programming in APL. Ray Cannon’s review was hampered because his machine did not have enough memory, at 4Mb, and he was working with Windows version 3.0 rather 3.1. The next release, APL*PLUS II/386 Version 5.0, looks as though it will be much easier to use, but until APL*PLUS becomes a full-blown Windows program the interface is bound to be rather convoluted.