STSC’s Double Whammy

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

Having just installed APL*Plus II Version 4.0, I must give credit to the Conservative party for introducing the perfect phrase to describe what STSC have done to us the poor punters out here in programming land. The last election will go down in (APL) history for that at least.

Evolution has come to programming land at last in the form of a new and deadly weapon )EVLEVEL. With the evolutionary paradigm of survival for those who least use nested arrays, I guess I shall be an early victim! In order to fit in with the emerging stIBMard (like a standard but somewhat less universal), APL*Plus II is evolving to converge with APL2. For those of us not convinced that APL2 actually has it right (all those functions with axis) this seems like bad news. You better believe it!

As the manual states…

"….STSC is changing the definitions of features that conflict most seriously with APL2 so that the two systems no longer differ. This means that you MUST change existing APL*Plus II applications if they use features whose definitions are being modified."

So what are all the changes? Well, for example, APL*Plus II used the monadic up-arrow as MIX (similar to disclose in APL2) whereas APL2 used it for FIRST. Monadic epsilon was used as TYPE rather than ENLIST. You get the general idea.

To make life a little easier, evolution is proceeding slowly. At )EVLEVEL 1, all the primitives behave as they used to; though this release introduces some syntactic enhancements:

• strand assignments can be parenthesized
• selective assignment is available

So far so good; selective assignment was always on my wish list.

Evolution can even go backwards — at )EVLEVEL 0, any feature which is going to be changed after )EVLEVEL 1 reports an EVOLUTION ERROR (if only Darwin had known about evolution errors!). We seem to have a real temporal twist here — evolution level 0 knows what is going to happen between evolution levels 1 and 2. Perhaps Oolon Colluphid could have used this rather than the Babel fish as the key of his argument in his epic philosophical tome "Well that about wraps it up for God".

Less seriously, perhaps a better approach would have been fuzzy evolution levels. At )EVLEVEL 1.1 the old MIX function gives up the ghost and becomes an EVOLUTION ERROR, whilst all the other primitives remain intact. Quite what would happen at )EVLEVEL 1.32742892 is another matter.

Finally at )EVLEVEL 2 the behaviour of the language is changed. About half of the changes are syntactic in nature rather than changes to the semantics of functions. The point is you still have to make modifications to your code. Unfortunately not all of the new behaviour is being implemented at )EVLEVEL 2. For example, attempts to use ENCLOSE-WITH-AXIS in place of SPLIT result in a NONCE ERROR, attempts to use partitioned enclose result in EVOLUTION ERROR.

Apparently, then, we have lost some functions at )EVLEVEL 2. Well not quite. In order to retain functional compatibility with )EVLEVEL 1 a series of new system functions have been introduced (bringing the grand total to 160, assuming the new system help file is comprehensive). To ensure your code works under all evolution levels, all uses of the MIX primitive function must be replaced by ⎕MIX etc. etc. etc. Helpfully, the new APL2 usages of some of these symbols are also introduced as system functions, for example ⎕ENLIST.

At this point, I notice that the documentation omits all mention of the changed behaviour of DISCLOSE (used to behave like APL2’s FIRST, now behaves like a sub-set of APL2’s DISCLOSE). One more little trap for the unwary.

Here is my version of the table that appears on page 7-4 of the new User Manual, I have extended it to include DISCLOSE.

First, semantic changes:

Note that at )EVLEVEL 2, DISCLOSE is implemented as a subset of APL2’s disclose function. The subset is compatible with the definition of MIX at )EVLEVEL 1.

Next, syntactic changes:

Note that ⎕REPL and ⎕EXPAND are functions rather than operators. They cannot be used in place of reduction or scan.

It may seem strange to you that vector index and strand assignment both report EVOLUTION ERRORs. It would be much more appropriate for strand assignment to report a SYNTAX ERROR. Vector index really is an evolution error since all that has been disallowed is indexing into strands of variables; it is still possible to use the current syntax to index into numeric strands. For example:

1 2 3[2]

still works at evolution level 2 (APL2 would report a RANK ERROR).

The manual states that a change to this behaviour is planned for a future release of APL*Plus II, so that the above expression will give the same error as APL2. Helpfully, we are even told how to avoid the problem by changing coding practices now.

Unfortunately, there is a window of "opportunity" when, by mistake or for some other reason, code can be written which will generate evolution errors in some future release! In other words, going through all the pain of migrating our code once is not enough for STSC, no, we have go through the experience twice. This gap could have been avoided simply by reporting an evolution error for all strand index operations.

So what about the new system functions? Are we really safe using them? The manual assures us that they will be available for ever and a day, so systems using them will work at any evolution level. Do I believe them? Well, almost. I just have a sneaking feeling that at evolution level 4 (or maybe 5), shortly after we have all regained our confidence, STSC will announce complete compatibility with APL2. Access to sharefile and DOS files will now be via auxiliary processors; ⎕ARBIN, ⎕POKE and all your other favourite system functions will be replaced by associated functions; the interpreter name will undergo a subtle change to APL*Plus 2…

Another cause of real pain is that apart from the use of )EVLEVEL 0 there are no tools to help with the migration process. At least IBM had the courtesy to provide )MCOPY and a workspace full of (relatively) useful functions to help you migrate from VS APL to APL2. Not content to cause us grief, STSC want to rub salt into the mixed metaphor too.

Oh well, mine is not to reason why, I just want to be carried screaming into the future.

Dave Piper.