Meeting at Morgan Stanley, 23 October

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

I was quite surprised to find that the lecture room for our meeting was attached to, and part of, the main dealing room at Morgan Stanley. Dealing rooms are not normally exposed to strangers, and allowing us to be close to the action seemed a good omen for the content of the meeting. I was not to be disappointed.

Smalltalk¶

The meeting started with a demonstration of a dealing system written in Smalltalk. Paul Wood and Clive Jackson showed off a really slick Windows system. It was hooked up to receive prices from the Stock Exchange, so that as soon as a price changed the appropriate cell on the screen briefly flashed, and there was a running ticker tape of the deals that had taken place. In true Smalltalk/Windows style, the system was event driven, responding to input from dealers and the Stock Exchange. There were masses of features to help the dealers make the best decisions, charts of historical data, forecasting tools etc. etc. When a trade has been made the details are sent to the Stock Exchange. The SE computer records the deal and then broadcasts it to all the market makers. The round trip, Morgan Stanley to SE and back, takes two seconds, a little statistic I found quite impressive. Another impressive statistic was that the system had been created by two people working on it from February this year. Smalltalk must be taken as a serious contender for application development.

A¶

Although the Smalltalk demonstration was impressive, the star attraction of the afternoon was, for me, a demonstration of A by Michael McConigley and Jon Willis. A is a dialect of APL written by Arthur Witney, and it is specially tailored for speed, speed and more speed. Huge quantities of data can be handled and applications can be developed really quickly.

The similarities between A and J are quite striking. John Brock told us about the genesis of J, when Arthur Witney spent an afternoon with Ken Iverson and created the first interpreter fragment for J. In An Implementation of J, (Iverson Software 1992), Roger Hui gives details of that famous meeting, in Appendix A entitled Incunabulum. (Did Roger deliberately choose Appendix A for Arthur and A?) The Appendix contains the C code of the interpreter fragment. The style of coding is very compact and concise, and looks like APL.

Like J, A has ⎕IO firmly fixed at 0. Operators such as reduction work along the first dimension by default, so that +/M in A is the same as +⌿M in APL. Nested arrays are grounded, so that scalars can be boxed. The rank operator looks identical to J or Sharp APL.

All functions are defined and edited in direct definition format, and → is not available for branching. Multiple line functions are possible, but are not so easy to enter and edit. This seems a very sensible restriction which would force people away from writing 1000 line functions with hundreds of labels. Michael gave us a glimpse of the functions used in a windowing utility, and all seemed to be one line functions doing just one task each. Also, all the variables in a function are local by default, and you have to take explicit action to access global variables. Maintenance must be much easier in this environment.

Functions can be assigned to identifiers, as in J and Dyalog APL, so that you can say SUM ← +/.

There is a new data type of Name, which is indicated with a back quote in front of the name, for example a ← `red `white `blue. All APLs have to process names when parsing code and maintaining the Symbol Table, and a good APL will have efficient facilities as part of the interpreter. A lets you get at these facilities. An array of names behaves in the same way as an array of characters, for example a=`white would return 0 1 0. There is a super-fast execute function (%) for name-type variables, so arrays of function and variable names become a practical proposition.

A uses most of the APL symbols, but there are several exceptions, such as # being used instead of ⌷ for the index function, and $ instead of ) for system functions, so you $off rather than )OFF. The major difference from normal APLs and J is that there are some reserved words in A, if else and time. The keyword time has caused some problems. It was added because everyone is hooked on speed, and a good timer is essential. However, everyone also wants to know the time of day! It just shows how keywords can make life difficult.

Nested arrays are specified using a semicolon as a separator, for example 1;"five";`name. This means that passing multiple arguments into a function looks exactly like ⎕FMT in APL*PLUS, Sharp APL etc., so you could have FUN(a;b;c;d).

I got quite excited when I saw the Context switching facilities. This is like ⎕NA, in that you can run A functions and get at A data in other Contexts. Contexts can also contain C programs, so A can call C programs. As in APL2, C programs can also call A. The syntax for getting at functions and data in other Contexts is rather neat, with a dot embedded in the name, and is very similar to the suggestions made by Robert Frey in Object Oriented Extensions to APL and J, in Vector 9.2. I wish this feature could be included in standard APLs. It would completely remove the problems almost everyone has with naming utilities so that they do not clash with names used in an application.

More excitements came up with the memory mapped files. There is no filing system as such, I-beam is used to link a file to a name and the entire file appears as an enormous vector in workspace. So, `filename ⌶ 1 data links the filename to the ‘variable’ data, and expressions such as (5678#data)←'A' will change the data directly in the file. Note the selective specification, as in APL2.

A+¶

John Brock told us that they had had lots of problems in programming Windows applications using Motif. As A can call Motif C functions directly there was no problem with the interface, the problem lay with Motif itself, which was slow and used lots of memory.

Incredibly, Morgan Stanley wrote a replacement for Motif in 3 months, which can be directly accessed from A. A now becomes A+ (or was it R?). There is only one copy in memory of the data on screen, and nothing has to be swapped backwards and forwards between the Windows and A+. We were given a staggering demonstration of a window displaying a huge matrix, I cannot remember now if it was 10 million or 1000 million integers. Scrolling around this monster and popping in changes was just as quick as looking at a tiny matrix. Inadvertently Michael changed every element of the array which stopped everything for about a minute, indicating the sheer size of the beast.

Window systems are developed with a simple-looking scheme using just 6 functions in the workspace, although there are many more hidden away in another Context. Straightforward instructions such as show `m is `array display m as an array in a window on screen. There is a similar simple syntax for buttons, radio buttons etc. etc. Callback functions were neatly handled using yet more special features of A+.

Most of the features for handling windows are written in A+. An impressive example was the ability to group a set of objects together in their relative positions on screen. You just move the objects around until they are vaguely in the right place and then group snaps them all together.

During the presentation some staggering statistics were thrown around. The Sparc II machines are equipped with 400 Mb of memory! Apparently some $20 million has been spent in the development of A and A+. It is quite definitely not for sale as it is seen as a tool giving Morgan Stanley the competitive edge. Development times are estimated to be 3 times better than C, and maintenance is 7 times better. It is also reckoned to be faster than C, as Arthur has spent so much time optimising every primitive; ⍋ is the fastest sort in the world!

It was fascinating to see that the developers had their desks actually in the dealing room, so that dealers could get problems solved immediately, and at any time. John Brock’s desk, car and home telephone numbers are on every dealer’s keyboard, so he is never off duty.

Normal APL¶

Having been shell-shocked by A, Shumit Rehman’s demonstration of the system for brokers dealing in cash bonds seemed a bit tame. It is written in APL*PLUS, and is in fact an advanced system full of features. The system was written some 3 years ago when Windows environments were not available, and it was interesting to compare the look and feel of the system with the Smalltalk system demonstrated earlier. Many of the facilities were the same, but the way one used them was quite different. I am not sure which is best. Windows are the current vogue, but the old ways can be just as fast and efficient, as Shumit demonstrated.

Conclusion¶

When starting to write up this meeting I chanced to open an old copy of Vector, 6.4 April 1990, where there was a note by Ed Shaw on a meeting of the NY/SIGAPL group at Morgan Stanley in New York. His reactions were just the same as mine — astonishment at the amounts of data, memory, workspace sizes and speed!